Gnus development mailing list
 help / color / mirror / Atom feed
From: Steven L Baur <steve@miranova.com>
Subject: Re: Strange memory hog^H^H^Hbehaviour with v0.30.
Date: 13 Feb 1996 09:56:31 -0800	[thread overview]
Message-ID: <m2spgfp0s0.fsf@miranova.com> (raw)
In-Reply-To: pp@pfawww.pp.se's message of 13 Feb 1996 08:15:25 -0800

>>>>> "Per" == Per Persson <pp@pfawww.pp.se> writes:

Per> I start up gnus and it connects to two servers and reads my mail with
Per> nnfolder, I read some mails and misc.kids.breastfeeding. Emacs now
Per> takes around 12MB of memory and I can live with that.

Per> Then I see I got this new mail from an old friend which I REALLY want
Per> to read so I hit 'g' to read it... then something strange happens...
Per> Emacs decide to go from 14MB to 32MB memory usage...

Per>  2648 pp         3   0 32608 24584 1600 R     2.3 62.5  0:29 emacs

Per> I use linux-1.3.62 and emacs-19.30, had the same problems on a
Per> solaris-2.3 machine... the problems was less evident on the sun (it
Per> just used around 27MB and not 32MB). This 'memory leak' doesn't heal
Per> itself but it doesn't leak anymore. Any ideas on what I should try?
Per> (Don't tell me Solamis and linsux sucks because I already know it).

Gnus virtual memory usage has been terrible (for me) with all versions
after v0.26, on both XEmacs 19.13 and Emacs 19.30.  I'm starting to
get better behavior from XEmacs with the most recent versions (it
grows to the unusable stage a bit slower).  This eliminates the only
thing I liked about running Gnus on GNU Emacs.

I was used to having a stable Emacs with Gnus at around 6MB virtual,
and XEmacs with Gnus at around 8MB virtual (measured from ps -ux
output).  This doesn't happen anymore.

Do you have 19.30 compiled to take advantage of the new mmapped malloc
on Linux?  I had hoped that along with the rewritten scheduler for the
1.3 kernels would clear up the thrashing that the 1.2.13 kernel so
readily goes into.

I wonder if it has something to do with nnfolder.  I haven't looked at
that code at all, and the bad behavior I've had did begin around the
time that the default ``Gcc: nnfolder:misc-(mail|news)'' was put in.
I've already verified that (on Linux anyway), the degraded virtual
memory behavior is independent of a.out -vs- ELF binary format.

Regards,
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.


  reply	other threads:[~1996-02-13 17:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-02-13 16:15 Per Persson
1996-02-13 17:56 ` Steven L Baur [this message]
1996-02-13 21:17   ` Per Persson
1996-02-14 16:06     ` Lars Magne Ingebrigtsen
1996-02-14 16:06   ` Lars Magne Ingebrigtsen
1996-02-15 12:31     ` Per Persson
1996-02-15 18:34       ` Lars Magne Ingebrigtsen
1996-02-15 21:50         ` Per Persson
1996-02-16  0:54           ` Lars Magne Ingebrigtsen
1996-02-16  8:50             ` Per Persson

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=m2spgfp0s0.fsf@miranova.com \
    --to=steve@miranova.com \
    /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).