From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Tomohiro Matsuyama <tomo@cx4a.org>, 17535@debbugs.gnu.org
Subject: bug#17535: 24.3.91; Problems with profiling memory
Date: Wed, 28 May 2014 14:04:34 -0400 [thread overview]
Message-ID: <jwv8upln5wh.fsf-monnier+emacsbugs@gnu.org> (raw)
In-Reply-To: <8338ftj1bb.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 28 May 2014 19:49:28 +0300")
>> 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
next prev parent reply other threads:[~2014-05-28 18:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-20 17:02 bug#17535: 24.3.91; Problems with profiling memory Eli Zaretskii
2014-05-20 19:01 ` Stefan Monnier
2014-05-20 19:33 ` Eli Zaretskii
2014-05-20 20:16 ` Stefan Monnier
2014-05-28 16:49 ` Eli Zaretskii
2014-05-28 18:04 ` Stefan Monnier [this message]
2014-05-28 23:45 ` Stefan Monnier
2014-05-29 17:01 ` Eli Zaretskii
2014-05-29 17:40 ` Stefan Monnier
2022-02-05 22:39 ` Lars Ingebrigtsen
2022-02-06 7:17 ` Eli Zaretskii
2022-02-06 22:48 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwv8upln5wh.fsf-monnier+emacsbugs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=17535@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=tomo@cx4a.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).