[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Memory again

From: Óscar Fuentes
Subject: Re: Memory again
Date: Tue, 06 Dec 2011 17:28:19 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> Just for the record: a *compile* buffer ended with 10M lines of
>> diagnostics emitted by a compiler. The emacs process jumped from 60MB to
>> 526MB of RES memory.
> On what OS?

Kubuntu 11.8 Linux version 3.0.0-13-generic #22-Ubuntu SMP x86_64.

> And was the size of the buffer comparable with 520MB?

Dunno. With the same emacs process (which is running as a daemon) after
repeating the steps that created that monster *compile* buffer I got:

Size, as reported by ibuffer: 29843302
Size of the file after saving the buffer's contents: 29843327
Number of lines: 1053239 (not 10M as reported on my previous msg)

The RES memory used by emacs stayed at 526MB.

Another issue is that if you press M-> (end-of-buffer) on that *compile*
buffer emacs uses 100% cpu and does freezes, apparently. After a while
(half a minute or so) pressing C-g makes emacs alive again and the point
is at the end of the *compile* buffer. Possibly it was fontifying the
buffer, as the last half of it is not fontified. After this, the RES
memory used by emacs increased to 554MB (from 526). A bit later it went
back to 526MB. Jumping at random on the buffer for a while increased the
memory usage to 533MB.

Again, killing that *compile* buffer makes no difference on the memory
used by emacs as reported by htop.

>> That was yesterday, and emacs keeps retaining that memory.
> Are you saying that you killed the *compilation* buffer and Emacs
> memory footprint didn't change at all?  I find that hard to believe.

I'm writing this message on that very same emacs process. Right now it
has 60 buffers, all of them with a size below 50KB and most below
10KB. As reported by `htop', the process is using 533MB of RES memory
and 630MB of VIRT memory.

>> I guess that as the buffer grew it was reallocated again and
>> again. Obviously fragmentation is at play here.
> If ralloc.c is used on the system where you did that, fragmentation
> should be prevented, especially in buffer text reallocations.  If
> ralloc.c is not used, I believe Emacs relies on the system's memory
> allocation to avoid fragmentation (that's why ralloc.c is not needed
> on those systems).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]