bug#17535: 24.3.91; Problems with profiling memory

[Stefan Monnier]

>> 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).

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).

> This looks like we count memory we just swept (i.e. released) as an
> allocation.

Yes.

> Unless I'm missing something, that makes no sense.

IIRC this was motivated by the idea of using memory as a crude
approximation for time.

>   (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.

> mentioned in my original report) is worse than I thought: there are a
> lot of macros in profiler.el that are defined using cl-macs.el, and
> they all have the same problem: they have no doc strings, and "C-h f"
> cannot find their sources, which makes reading the code unbearably
> complicated.

That's something we need to fix in cl-macs.el, indeed.


        Stefan