bug#17535: 24.3.91; Problems with profiling memory

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 17535@debbugs.gnu.org
> Date: Sat, 05 Feb 2022 23:39:23 +0100
> 
> > 3. Displaying a memory profile after several minutes shows clear signs
> >    of overflow:
> >
> >   - command-execute                                         151,652,741   0%
> >    - call-interactively                                     151,650,661   0%
> >     - dired-x-find-file                                      44,210,847   0%
> >      - find-file                                             44,210,847   0%
> >       - find-file-noselect                                   44,209,884   0%
> >   ...
> >     - normal-backup-enable-predicate                      7,091,148  -1%
> 
> I'm not able to reproduce this on the current trunk.

The original report was in a 32-bit build, and we now have bignums, so
if a 32-bit build doesn't reproduce that, it means bignums fixed that.

> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 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.
> 
> If we started to try to count how much was freed, too, then the numbers
> would become more arbitrary?  Because GC will free things
> asynchronously, etc.  Just counting the allocations sounds like a valid
> thing to do to me.
> 
> But perhaps counting frees would be nice as an option?

I have since arrived at the conclusion that the so-called "memory"
profile doesn't actually profile memory allocations, and is
more-or-less useless, especially in Emacs that has SIGPROF support
(which I guess means everywhere?).  So I think it's okay to just close
this bug report.