Yeah, it's true – even though it's not the most immediately intuitive measure, cumulative bytes allocated is really the most straightforward and informative information you can report here.
> On May 6, 2015, at 10:21 PM, Jameson Nash <[email protected]> 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] 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
