From: Wes Hardaker <wes@hardakers.net>
Subject: memory usage results (ack!)
Date: Wed, 06 Feb 2002 17:36:33 -0800 [thread overview]
Message-ID: <sdwuxqoyxq.fsf@wanderer.hardakers.net> (raw)
Ok, so I upgraded my xemacs to 21.5.4 (the most recent beta) and
played with gnus for a while:
hardaker 1649 10.2 34.3 98716 87628 pts/2 S 16:53 3:32 xemacs
^^^^^
nice nearly 100meg size.
This time, however, I compiled xemacs with memory debugging support.
Quickly tinking to figure out how to use it produces:
(progn
(mapcar (function (lambda (z)
(insert (format "%s:\n" (buffer-name z)))
(mapcar (function (lambda (x) (insert (format " %s %s\n" (symbol-name (car x)) (cdr x))))) (buffer-memory-usage z))
z)) (buffer-list t)))
The above prints memory usage stats for every buffer in xemacs.
Example output:
*scratch*:
text 8216
markers 1824
extents 0
other 512
nil nil
actually-requested 4357
malloc-overhead 3921
gap-overhead 2274
dynarr-overhead 0
So, the text of the scratch buffer is small (8216), and the rest you
can guess it (I won't elaborate here).
So, sorting the entire output by sizes > 1M (using perl (gasp):
% perl -n -e '$x = $_ if (/:/); print $x, $_ if (/ \d{7}/);
*nntpd*:
text 34088184
*nntpd*:
actually-requested 29622319
*nntpd*:
gap-overhead 4365513
*Gnus agent overview*:
text 34088184
*Gnus agent overview*:
actually-requested 1181163
*Gnus agent overview*:
gap-overhead 32805805
Yikes. Ok, so the nttpd buffer (note all these have a leading space)
is 34megs. The agent overview is also 34 megs. Double ouch. What I
don't get is that the actual size of the buffer is much smaller (92097
of the latter) in, so the text field obviously isn't getting cleaned
up these days in either buffer. But why? So, lets be brave, save
this message buffer and kill both these buffers (not that it should
matter from a message sending point of view, but I don't remember how
well gnus deals with important deleted buffers).
Ahhh:
hardaker 1649 9.3 10.0 32332 25668 pts/2 S 16:53 3:53 xemacs
^^^^^
So, the question is (especially for the emacs experts): What's
happening with these two buffers and how do we fix it?
--
"Ninjas aren't dangerous. They're more afraid of you than you are of them."
next reply other threads:[~2002-02-07 1:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-07 1:36 Wes Hardaker [this message]
2002-02-07 22:20 ` Agent .overview files not getting truncated (was Re: memory usage results (ack!)) Wes Hardaker
2002-02-07 23:24 ` ShengHuo ZHU
2002-02-08 5:08 ` Wes Hardaker
2002-02-08 6:02 ` ShengHuo ZHU
2002-02-08 15:44 ` Wes Hardaker
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sdwuxqoyxq.fsf@wanderer.hardakers.net \
--to=wes@hardakers.net \
/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.
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 NNTP newsgroup(s).