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 <scott.paul.jo...@gmail.com> 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, ele...@gmail.com wrote: >> >> >> >> On Saturday, May 2, 2015 at 2:45:16 AM UTC+10, cormu...@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 >> >>
