[Top][All Lists]

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

Re: warn-maybe-out-of-memory

From: Dmitry Antipov
Subject: Re: warn-maybe-out-of-memory
Date: Fri, 11 Jul 2014 12:43:39 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

On 07/11/2014 10:50 AM, Eli Zaretskii wrote:

But if this warning is to be useful, it should catch the majority of
the cases, otherwise we are just wasting cycles.  With the current
test, many cases of visiting files that cannot be accommodated will go
undetected, thus rendering all this feature useless.

With this feature, I'm just trying to redirect user to `find-file-literally'
if file looks so large that `find-file-noselect' is likely to run out of
memory.  What other cases do you mean?

Since it's only a warning that doesn't prevent visiting a file, it is
better to err on the other side of the truth.  E.g., apply some
heuristics as to the average expansion factor, perhaps dependent on
the locale.

IIUC there are no reliable heuristics here.  For example, produce_charset
and compose_text may allocate substantial amount of memory to represent
`composition' and `charset' extra properties, and we need to read and
decode everything to find all places where such an extra properties
should be attached.

And don't forget that even for plain-ASCII files we
allocate the gap in addition to the text itself, so the mere size of
the file is simply _never_ the correct value, it is always an
underestimation.  IOW, this test is always biased towards lower

Unless someone still uses a machine with 64K RAM, initial gap size
is very small in comparison with file sizes we're talking about.

If we don't do something like that, then I wonder what exactly is the
use case that benefits from this warning?

We don't need to do "something like that", i.e. we don't need a precise
estimation.  OSes are tricky about memory management; overall VM picture
may drastically change when file reading is in progress, etc.  With a lot
of constraints you can't predict, estimate and control, precise estimation
just makes no sense.

It is IMO inappropriate for a minor feature like this one to abort
Emacs.  Who knows what the Linux kernel developers will introduce
tomorrow that could possibly fail the function?  It is none of this
feature's business to be the place where C stack smashing is detected.
So my vote is for returning nil and perhaps displaying a warning.



reply via email to

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