bug#17535: 24.3.91; Problems with profiling memory

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Tomohiro Matsuyama <tomo@cx4a.org>,  17535@debbugs.gnu.org
> Date: Wed, 28 May 2014 14:04:34 -0400
> 
> >> It only counts allocation, so "alloc+free+alloc" counts as 2 allocs.
> > Why doesn't it count a call to 'free' as a deallocation?
> 
> Original reason is that the memory profiler was mostly meant as a way to
> get profiling with the need for a timer (using memory allocation as
> a crude approximation of time).

But since now we do have timer-based CPU profiling, we no longer need
this approximation, right?

> Other reason is that deallocation largely takes place during GC and it's
> unclear to which functions/backtraces to attribute the corresponding
> negative (attributing them to the backtrace that happens to be current
> during GC would make the numbers pretty arbitrary).

First, there are quite a few places where we allocate and deallocate
memory for things other than Lisp objects.  Normally, such memory is
deallocated right away, or very soon, after it is no longer needed.
In those cases, we should attribute the memory freeing to the current
function/backtrace.

And second, I understand the limitations caused by GC, but I think we
should still attribute memory freed during GC to GC itself.  That way,
at least at some high enough level the positive and negative probes
will balance, and the memory profile won't look like one giant leak.

If we don't count free as a negative allocation, can you envision a
situation for which the memory profile, as we have it now, would be a
useful tool?  Because I can't.

> >   (defvar profiler-report-cpu-line-format
> >     '((50 left)
> >       (24 right ((19 right)
> >              (5 right)))))
> >
> >   (defvar profiler-report-memory-line-format
> >     '((55 left)
> >       (19 right ((14 right profiler-format-number)
> >              (5 right)))))
> >
> > Is it possible to have doc strings for these variables, or at least a
> > comment that explains this data structure, the meaning of each field,
> > and its possible values?  Otherwise, there's no way of adjusting them
> > when the report format is changed in some way.
> 
> I'm not familiar with this part of the code.  Hopefully Tomohiro can help.

I hope so too.