[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs memory management and sluggishness
From: |
Óscar Fuentes |
Subject: |
Re: Emacs memory management and sluggishness |
Date: |
Sat, 27 Jul 2019 14:36:25 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
Eli Zaretskii <address@hidden> writes:
>> From: Óscar Fuentes <address@hidden>
>> Date: Fri, 26 Jul 2019 21:20:17 +0200
>>
>> Since a week or two typing normal text (i.e. writing this message) even
>> in Fundamental Mode shows an annoying lag betwenn the keypress and the
>> character showing on the screen. Sometimes it affects entire key
>> sequences, and I'm no fast typist.
>
> Is there any correlation between the lag and the GC cycles? (Turn on
> garbage-collection-messages to see.)
Ok. Too bad that the gc messages are not appended to *Messages*.
Indeed, the lag is caused by gc.
> If it does, then there's only
> one problem to investigate: why you have frequent GC cycles.
>
> And what is your value of gc-cons-threshold?
(setq gc-cons-threshold (* 20 1000 1000))
setting it to (* 2 1000 1000)) shortens the gc pauses, but I have the
impression that they occur with the same frecuency.
>> So my questions are: do we have a problem with memory fragmentation?
>
> We shouldn't have. However, there's a question whether the particular
> development snapshot of a month ago you are using had some
> memory-related bug.
>
>> ((conses 16 4505904 1124616)
>> (symbols 48 76877 18)
>> (strings 32 340997 83083)
>> (string-bytes 1 10456288)
>> (vectors 16 688370)
>> (vector-slots 8 24140524 2173062)
>> (floats 8 1621 1825)
>> (intervals 56 112123 94665)
>> (buffers 992 449))
>>
>> I wonder how this ends using 1.1 GB of RSS.
>
> It doesn't. But all these measures don't include the memory we
> allocate directly, not via Lisp objects.
>
> Also, can you tell how many bytes of text do you have in all your
> buffers? E.g., with this toy program:
>
> (let ((stext 0))
> (dolist (b (buffer-list))
> (setq stext (+ stext (buffer-size))))
> stext)
416484 (#o1455344, #x65ae4)
> Having said all that, it isn't clear to me that an RSS of 1.1 GB per
> se is something exceptional in a long-running session. E.g., the
> Emacs 26.2.90 session where I'm typing this, which is running for 44
> days, shows an RSS of 360 MB with VM Size of 514 MB, and this is a
> 32-bit build of Emacs --with-wide-int. So your 1.1 GB is not
> necessarily a sign of a problem.
Until now my experience was similar. Emacs memory usage increased
steadily to about 400 MB but then it stayed there. This is the first time
that I see it over 1 GB. The largest memory usage I observed until now
was 700 MB, but that was visiting very large PDF files and navigating
through many pages.
Since my previous message RSS increased 30 MB.
- Emacs memory management and sluggishness, Óscar Fuentes, 2019/07/26
- Re: Emacs memory management and sluggishness, Eli Zaretskii, 2019/07/27
- Re: Emacs memory management and sluggishness,
Óscar Fuentes <=
- Re: Emacs memory management and sluggishness, Eli Zaretskii, 2019/07/27
- Re: Emacs memory management and sluggishness, Óscar Fuentes, 2019/07/27
- Re: Emacs memory management and sluggishness, Eli Zaretskii, 2019/07/27
- Re: Emacs memory management and sluggishness, Joseph Mingrone, 2019/07/31
- Re: Emacs memory management and sluggishness, Óscar Fuentes, 2019/07/31
- Re: Emacs memory management and sluggishness, Joseph Mingrone, 2019/07/31
- Re: Emacs memory management and sluggishness, Óscar Fuentes, 2019/07/31
- Re: Emacs memory management and sluggishness, Joseph Mingrone, 2019/07/31
- Re: Emacs memory management and sluggishness, Eli Zaretskii, 2019/07/31