* why is emacs using all my memory
@ 2010-06-24 9:22 David Pleydell
0 siblings, 0 replies; 2+ messages in thread
From: David Pleydell @ 2010-06-24 9:22 UTC (permalink / raw)
To: help-gnu-emacs
I have writen a program in C (called from a script in R) that I run inside emacs. The program is still in development phase so I have it spit out lots and lots and lots of text for monitorring progress. The program runs for several days.
After half a day emacs is now using over 3Gb of RAM (almost half of my RAM). So I killed all the old text and purged the kill ring using M-:(setq kill-ring nil). But this hasn't freed the 3Gb. I have no idea what emacs is doing with this 3Gb, there are no other processes running. How can I diagnose what process within emacs is using this memory? Perhaps there is there some kind of "M-x top"?
thankx
David
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: why is emacs using all my memory
[not found] <mailman.3.1277391050.18733.help-gnu-emacs@gnu.org>
@ 2010-06-24 15:47 ` Pascal J. Bourguignon
0 siblings, 0 replies; 2+ messages in thread
From: Pascal J. Bourguignon @ 2010-06-24 15:47 UTC (permalink / raw)
To: help-gnu-emacs
David Pleydell <d_pleydell@yahoo.com> writes:
> I have writen a program in C (called from a script in R) that I run
> inside emacs. The program is still in development phase so I have it
> spit out lots and lots and lots of text for monitorring progress. The
> program runs for several days.
>
> After half a day emacs is now using over 3Gb of RAM (almost half of my
> RAM). So I killed all the old text and purged the kill ring using
> M-:(setq kill-ring nil). But this hasn't freed the 3Gb. I have no idea
> what emacs is doing with this 3Gb, there are no other processes
> running. How can I diagnose what process within emacs is using this
> memory? Perhaps there is there some kind of "M-x top"?
Better than setting kill-ring to nil, I think you should use
(buffer-disable-undo).
And then copy a character or two again, to free the old undo stuff.
You may also want to set comint-buffer-maximum-size.
But foremost, I would advise you to use redirection to a file, and use
from time to time tail or tail -f.
cmd > /tmp/big.output &
tail -40 /tmp/big.output
tail -f /tmp/big.output & pid=$? ; sleep 60 ; kill $?
If there are easily identified lines that are ignorable, grep -v may
also come handy:
cmd | grep -v 'do not care' > /tmp/medium.output &
tail -f /tmp/medium.output
Yes, it's unfortunate that it requires some pre-thinking.
The alternative would be to design a shell that would automatically
insert redirection points (ptys), and that would stop outputing to the
terminal when output is too big, but store it automatically to a spool
file. Then, in a TTY, it could display transiently the current lines,
but in a dumb terminal (such as emacs shell), it would not output
anything unless requested by the user (eg. skipping directly to the end, or
wherever the user wants à la less(1)).
What's more, a mechanism to distinguish important messages from dumb
logs would allow such a shell to keep a list of important message to be
read and acknowledged, while the dumb logs would just fill the spool and
be of use only in case of problem.
On the old systems of lore, there were such "shells", to manage the
messages directed to the operators.
--
__Pascal Bourguignon__
http://www.informatimago.com
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2010-06-24 15:47 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <mailman.3.1277391050.18733.help-gnu-emacs@gnu.org>
2010-06-24 15:47 ` why is emacs using all my memory Pascal J. Bourguignon
2010-06-24 9:22 David Pleydell
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.