GNU bug report logs - #17535
24.3.91; Problems with profiling memory

Previous Next

Package: emacs;

Reported by: Eli Zaretskii <eliz <at> gnu.org>

Date: Tue, 20 May 2014 17:03:01 UTC

Severity: wishlist

Found in version 24.3.91

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Tomohiro Matsuyama <tomo <at> cx4a.org>, 17535 <at> debbugs.gnu.org
Subject: bug#17535: 24.3.91; Problems with profiling memory
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).

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




This bug report was last modified 3 years and 136 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.