[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#17535: 24.3.91; Problems with profiling memory
From: |
Eli Zaretskii |
Subject: |
bug#17535: 24.3.91; Problems with profiling memory |
Date: |
Sun, 06 Feb 2022 09:17:01 +0200 |
> 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.