Gnus development mailing list
 help / color / mirror / Atom feed
From: dhall@illusion.apk.net (d. hall)
Cc: ding@ifi.uio.no, mpt95aes@pt.hk-r.se
Subject: Re: (None)
Date: 21 Feb 1996 21:48:30 -0500	[thread overview]
Message-ID: <x67mxgf535.fsf@illusion.apk.net> (raw)
In-Reply-To: "Steven L. Baur"'s message of Wed, 21 Feb 1996 15:06:41 -0800

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


      reply	other threads:[~1996-02-22  2:48 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-02-21 23:06 (unknown) Steven L. Baur
1996-02-22  2:48 ` d. hall [this message]

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=x67mxgf535.fsf@illusion.apk.net \
    --to=dhall@illusion.apk.net \
    --cc=ding@ifi.uio.no \
    --cc=mpt95aes@pt.hk-r.se \
    /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).