(unknown)

(unknown)

[Steven L. Baur]

Sender: steve@deanna.miranova.com
To: mpt95aes@pt.hk-r.se
CC: ding@ifi.uio.no
Subject: Re: September Gnus 0.40 is released
X-Url: http://www.miranova.com/%7Esteve/
References: <w8s68d1ct34.fsf@eistla.ifi.uio.no>
	<m2d979cqkp.fsf@deanna.miranova.com> <rjohqt0wgx.fsf@ssv4.dina.kvl.dk>
	<m2n36cwlkn.fsf@deanna.miranova.com> <lvbumstkkh.fsf@ariel.pt.hk-r.se>
From: Steven L Baur <steve@miranova.com>
Date: 21 Feb 1996 15:06:37 -0800
In-Reply-To: Andy Eskilsson's message of 21 Feb 1996 13:50:22 -0800
Message-ID: <m27mxg1doi.fsf@deanna.miranova.com>
Organization: Miranova Systems, Inc.
Lines: 79
X-Mailer: September Gnus v0.40/XEmacs 19.13
Mime-Version: 1.0 (generated by tm-edit 7.43)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Andy" == Andy Eskilsson <mpt95aes@pt.hk-r.se> writes:

Andy> / Steven L Baur <steve@miranova.com> wrote:
Andy> | 
Andy> | A hard choice has already been made to abandon support for earlier
Andy> | versions of Emacs.  Are we also prepared to abandon lesser endowed
Andy> | systems as well?

Andy> This shouldn't stop us(ehm the Gnus developers) from keeping eyes open
Andy> for memory leaks, memory hogging stuff that really ain't worth it?

Andy> I don't know much about the memoryhandling in emacs/gnus, but I think
Andy> you are talking about two different memory-hogs here:

Andy> 1. Memory leaks (I think it is possible!), features that take a large
Andy>    hunk of memory, that they(the user/feature) might not need.

Andy> 2. Feature 'leaks', simply more features, more memory.

Andy> I think this thread started with the first point, and Steven is
Andy> talking about the second?

I wish I could say for sure.  On the one hand, it does not seem
reasonable to me that XEmacs should keep growing after a point.  On
the other hand, I am quite willing to pay the memory price for
features I want/need.  Thus memory comparisons to Netscape (a
``competitor'') are apropos, comparisons to XEmacs running without
toolbars/3d graphics & X Windows are not (to me, personally).  On the
gripping hand, Lars is reporting much smaller numbers than I get.

I've just run two tests that indicate that perhaps the growth I'm
experiencing is just the price of running XEmacs.  The last two tests
I've done have been against sgnus v0.26 (which was reasonably memory
stable), and a modified XEmacs without 64k lstreams buffers (part of
the problem that can plague memory-limited boxes with backends like
nnmh).  v0.26 ran the smallest, as expected, but the difference was
much smaller than I expected, and could be explained away as the
addition of new features ...  Modifying the 64k lstreams buffers to be
8k caused a slight *increase* in memory usage.
The numbers follow, FYI.

Memory leaks should be fixed where possible.  Memory intensive
features should be identified and documented.  I am uncertain how your
second category differs from the latter.

Note that it costs 1.2MB virtual to read 48 articles.  The articles
were selected from the same nnml group.  I hit space bar to read the
first article, then hit n until hitting the last article.  After
taking a memory reading, I marked as unread each article for the next
test.

[Linux 1.2.13/ELF, PID 12917 is an editing-only session for comparison]
USER       PID %CPU %MEM  SIZE   RSS TTY STAT START   TIME COMMAND
(v0.26/after loading Gnus)
steve    12917  0.6 14.6 2823 4564  ?  S    10:33   0:19 /usr/local/bin/xemacs
steve    13590 58.1 22.6 4763 7052  ?  S    11:24   1:44 /usr/local/bin/xemacs
(v0.26/after reading 48 articles + (garbage-collect))
steve    12917  0.6 15.5 2823 4828  ?  S    10:33   0:21 /usr/local/bin/xemacs
steve    13590 46.8 26.7 5907 8316  ?  S    11:24   2:43 /usr/local/bin/xemacs

(v0.40/after loading Gnus)
steve    12917  0.5 15.5 2823 4828  ?  S    10:33   0:21 /usr/local/bin/xemacs
steve    13695 70.8 25.5 5171 7948  ?  S    11:30   1:53 /usr/local/bin/xemacs
(v0.40/after reading 48 articles + (garbage-collect))
steve    12917  0.5 15.5 2823 4828  ?  S    10:33   0:21 /usr/local/bin/xemacs
steve    13695 62.6 29.2 6231 9124  ?  S    11:30   2:47 /usr/local/bin/xemacs

(v0.40/8k lstreams/after loading Gnus)
steve    12917  0.2 10.0 2871 3132  ?  S    10:33   0:30 /usr/local/bin/xemacs
steve    16915 39.7 25.6 5254 7988  ?  S    13:37   2:14 /usr/local/bin/xemacs
(v0.40/8k lstreams/after reading 48 articles + (garbage-collect))
steve    12917  0.2 12.2 2923 3808  ?  S    10:33   0:31 /usr/local/bin/xemacs
steve    16915 40.6 29.5 6378 9216  ?  S    13:37   3:03 /usr/local/bin/xemacs

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

Re: (None)

[d. hall]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2595 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----

ð thus on Wed, 21 Feb 1996 15:06:41 -0800, Steven virtually scripted...

Steven> Memory leaks should be fixed where possible.  Memory intensive
Steven> features should be identified and documented.  I am uncertain how
Steven> your second category differs from the latter.

I've been doing several memory streamlining.  Often times I find myself
shutting down emacs, and restarting it, since I don't like having a >12M
process running around, when I only have 16megs (the only is sarcasm =) to
play with w/o swap.  I maintain a 20 meg swap space.

barebones emacs with my features.

USER       PID %CPU %MEM SIZE  RSS TTY STAT START   TIME COMMAND
dhall      264 11.3 15.0 1318 2240 pp0 T    21:41   0:01 emacs

  PID TTY MAJFLT MINFLT  TRS  DRS SIZE SWAP  RSS SHRD  LIB  DT COMMAND
  264 pp0    436    597 1472 1068 2540    0 2540 1720    0 203 emacs

my normal gnus reading news and mail (i decide to scrap VM in favour of
keeping with just one feature package to reduce memory usage, since each
have overhead associated with it).

USER       PID %CPU %MEM SIZE  RSS TTY STAT START   TIME COMMAND
dhall      214  3.4 31.8 6741 7748 v01 S    20:50   1:45 emacs -geometry 81x50

I normally try to keep my newsgroup access to below 300 articles, and I
still get this bloat.  My base emacs I have pretty much all non-essential
personal elisp hacks as autoloads, so I can forestall any memory usage till
the last possible second.

My normal free output
             total       used       free     shared    buffers
Mem:         14896      14640        256       5356       2068
- -/+ buffers:            12572       2324
Swap:        19968       4944      15024

I'm tempted to buy some more RAM, but as with most people in the PC
community, 16 megs is almost surely the "optimum".  And IMHO I've never
been one to go for the current software trend of "we've got the hardware,
why don't we abuse it?".  Are there any incorporated features I can do,
i.e. a list or possible ways to save memory?

d.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBMSvZeYX26urqpgG1AQEyMQP/Z0jUZA1b9tj/DlCp6nwYRNlTVxB/SaEo
f54hAwpnc0unKYWEwAyjc3qrPXcvuqYN0qV68NXEVvSnOFdrvsQ21QHnPwVqCctI
fsmNt9wzw514nN7/5731aPQIpruc3avWn/BGGpK3MQ6zl/w4eVgmu4mltSUPLDF5
N23fRIl+oWI=
=Nihq
-----END PGP SIGNATURE-----
--
Dump:
  A Perl statement that is one of the many ways to get a Perl program
  to produce a core file.  Most of the other ones are undocumented.
                                ~ wall & schwartz, programming perl