Re: Implementing image support for kitty terminal

[Jose A Ortega Ruiz]

On Fri, Sep 09 2022, Óscar Fuentes wrote:

> Jose A Ortega Ruiz <jao@gnu.org> writes:
>
>>> How is kitty not heavy-weight?
>>> A graphical emacs already has all that.
>>
>> After 4-5 days of continous use, a graphical emacs is consuming around
>> 2Gb for me, sometimes 3Gb; emacs-nox+kitty, combined, with the same
>> workload except displaying images, is under 500Mb.  foot is even
>> slimmer.
>
> In my experience of many years, Emacs RSS usage stabilizes around ~500
> MB, which is what it is using right now in this box with M-x
> emacs-uptime of 36 days. When it grows larger is because of some
> extension eating memory or, more rarely, a bug in Emacs.
>
> Take a look at the output of M-x memory-report.
>
> If that is not enlightening, look for extensions that you use in GUI
> Emacs and not in TUI Emacs, disable them and see if GUI Emacs' memory
> keeps growing.

thanks for your advice, but i've already tried all that and there's no
obvious candidate.  my conclusion is that it's the rendering to x
surfaces that somehow is leaking memory, maybe when it refreshes, or
colors or some other graphical resource (but not specially images,
memory raises without displaying them).  there is no extension that i
don't use in one place and not the other, with the exception of
doc-view, but i know it's not the cause because memory grows up in X
even when i don't use it.  likewise, i know gnus is not the cause, nor
notmuch, because i see the effect with either.

judging from your experience, it must be an external package that causes
the leak, in graphical mode only, but i haven't been able to pinpoint
one so far.  perhaps i'll try with vertico/corfu next.

all that said, i'd be a bit surprised if the leak came from a pure elisp
package...

thanks,
jao
-- 
The enjoyment of one's tools is an essential ingredient of successful
work. – Donald E. Knuth