[Top][All Lists]

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

bug#33275: 27.0.50; Image cache pruning

From: Eli Zaretskii
Subject: bug#33275: 27.0.50; Image cache pruning
Date: Mon, 05 Nov 2018 19:27:28 +0200

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 33275@debbugs.gnu.org
> Date: Mon, 05 Nov 2018 17:35:51 +0100
> >> If you visit a, say, 16GB file, then, indeed, it's expected that Emacs
> >> grows to 16GB (or more).  But if you're just calling `image-size' on a
> >> bunch of files (each of which is a lot smaller than that), it's rather
> >> unexpected that that's going to blow up Emacs.
> >
> > What was the sum of sizes of all the files you used to reproduce the
> > problem?
> I think it's sufficient to run Emacs over 2GB worth of .png files to
> make Emacs grow to 16GB (which will kill it on this laptop).
> But it'll vary on how well-compressed the .png files are, I guess,
> because I think Emacs caches the, er, pixmaps and not the files?  I
> don't remember.

I think it's reasonable to expect 2GB worth of image files to take
several times that in memory.  (Btw, visiting a 16GB file usually
takes twice that much during insert-file-contents.)

I think we should try to add some code that would call
display_malloc_warning and/or memory_full, before the system runs out
of memory.  That should be enough to prevent OOM in such cases.  Can
you spot why we never called memory_full in this case?

reply via email to

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