As far as I can tell, this should be a pretty simple change… maybe it will be done this afternoon…
Would it break anything to change @timed to return the extra information as well? It seems like rather a bit of duplication, @time does all the work, and then prints stuff out, and @timed returns a subset of the same information… I would think @time could just call @timed, print out stuff and return the value. I think that simply adding some counters in jl_gc_counted_malloc, jl_gc_counted_free, jl_gc_counted_realloc_with_old_size (in julia/src/gc.c) would do the trick. Finally, I think that jl_gc_counted_realloc_with_old_size has a problem, if somebody uses realloc to *shrink* something… It blindly adds (sz - old) to the counter of allocated bytes, but it should check the result, and add (old - sz) to the counter of freed bytes if it is negative. Should I submit a PR and fix that bug? Scott > On May 6, 2015, at 11:09 PM, Jameson Nash <[email protected]> wrote: > > You could, but it wouldn't significantly improve the items that I mentioned. > > If someone is interested in opening an issue / PR, I think that reporting of > the number of allocation events would be more useful ("N bytes allocated for > M objects"), since the performance cost is likely more directly correlated to > the number of allocations rather than their cumulative size. It would also > probably be a good "up for grabs"-type project. > > > On Wed, May 6, 2015 at 10:55 PM Scott Jones <[email protected] > <mailto:[email protected]>> wrote: > Would it be possible to force a garbage collection at the beginning of @time > to prevent that issue? > The maximum memory used would be very useful information for me... > > > On Wednesday, May 6, 2015 at 10:21:46 PM UTC-4, Jameson wrote: > I suspect including bytes freed may be much more misleading than leaving it > out. > > Bytes allocated between to points in time is easy to calculate and easy to > understand since it is a simple summation operation. Conversely, bytes freed > depends on the gc heuristics in use, and not as strongly correlated to the > program. We could instead try to give the maximum memory in use by the > program at any intermediate gc point, but that also has most of the same > pitfalls as trying to calculate the bytes freed (since it is unclear whether > to count memory that was allocated prior to the call but that became > collected as garbage sometime before the `@time` call returned, under the > assumption that a gc call occurred). > > On Wed, May 6, 2015 at 8:21 PM Scott Jones <[email protected] <>> wrote: > +1, yes, definitely! > > > On Friday, May 1, 2015 at 8:28:17 PM UTC-4, Stefan Karpinski wrote: > Maybe we should include bytes freed as well. > > On May 1, 2015, at 8:15 PM, [email protected] <> wrote: > >> >> >> On Saturday, May 2, 2015 at 2:45:16 AM UTC+10, [email protected] >> <http://mac.com/> wrote: >> Yes, that makes much more sense! So it's really "byte allocations" rather >> than "bytes allocated". Thanks. >> >> Its bytes allocated not bytes in use. >> >> bytes in use = bytes allocated - bytes freed
