[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#17535: 24.3.91; Problems with profiling memory

From: Stefan Monnier
Subject: bug#17535: 24.3.91; Problems with profiling memory
Date: Tue, 20 May 2014 16:16:13 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

>> > 2. How to interpret the "memory profile"?  What does a line such as
>> >    this in the profile mean:
>> >   - execute-extended-command                                  973,272  20%
>> >    How were the 973,272 bytes counted, and what are they 20% of?  The
>> >    ELisp manual, where this facility is described, does not explain
>> >    how to interpret the profiles, and neither can I find anything
>> >    about that in the doc strings.
>> It's the number of bytes "allocated from the system" during execution of
>> this function.
> But these numbers are huge.  I have hard time believing that all those
> bytes were allocated in just few minutes of an almost-idle Emacs.

It only counts allocation, so "alloc+free+alloc" counts as 2 allocs.
1MB of allocation over a few minutes of use doesn't sound particularly
odd to me.

>> This "allocation" is poorly defined: we don't track allocation of
>> individual objects but of things like cons_blocks.
> Do we only track allocations of Lisp objects, or just any calls to
> xmalloc?

Can't remember.

>> >   etc.: I see no percentage numbers except 1%, 0%, and -1%.
>> This is just most likely a wrap-around due to too-large integers.
> Definitely.  I thought these were already fixed, but it looks they
> aren't.  I will try to take a better look.  Are there any reasons not
> to do this calculation in floating-point?

The raw counts need to be integers because we can't allocate during the
sampling, but all the Elisp code could use floating point, I think.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]