[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).
- Re: Memory again, (continued)
- Re: Memory again, Eli Zaretskii, 2011/12/06
- Re: Memory again, Stefan Monnier, 2011/12/06
- Re: Memory again, Eli Zaretskii, 2011/12/07
- Re: Memory again, Dmitry Antipov, 2011/12/07
- Re: Memory again, Eli Zaretskii, 2011/12/07
- Re: Memory again, Stefan Monnier, 2011/12/07
- Re: Memory again, Carsten Mattner, 2011/12/08
- Re: Memory again, Dmitry Antipov, 2011/12/08
- Re: Memory again, Carsten Mattner, 2011/12/09
- Re: Memory again, Eli Zaretskii, 2011/12/06
Re: Memory again,
Óscar Fuentes <=
- Re: Memory again, Stefan Monnier, 2011/12/06
- Re: Memory again, Nix, 2011/12/11
- Re: Memory again, Tim Connors, 2011/12/14
- Re: Memory again, Eli Zaretskii, 2011/12/14
- Re: Memory again, Tim Connors, 2011/12/14
- Re: Memory again, Eli Zaretskii, 2011/12/15
Re: Memory again, Óscar Fuentes, 2011/12/14
Re: Memory again, Eli Zaretskii, 2011/12/15
Re: Memory again, Stefan Monnier, 2011/12/16
Re: Memory again, Nix, 2011/12/17