Gnus development mailing list
 help / color / mirror / Atom feed
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."



             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).