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