bug#30943: save-hist creates massive cache file

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: cfindeisen@google.com,  30943@debbugs.gnu.org
> Date: Fri, 30 Mar 2018 01:25:23 -0400
> 
> Eli Zaretskii wrote:
> 
> > I actually find that to be a nuisance even for visiting files.  With
> > 64-bit builds, this warning makes very little sense.
> 
> 32-bit builds are almost dead, so you may want to revisit the default.
> (See trend at https://debbugs.gnu.org/stats/emacs.html )

Yes, I think we should significantly increase the default value of
large-file-warning-threshold.  I always enlarge it in my .emacs,
because the default is even small enough to allow me reading my email
without annoying questions.

> But isn't it about how much physical memory the system has?

That's one factor to consider, yes.  But even that is normally what?
8GB nowadays?  And VM is then 2 or 4 times that?

> The largest el(c) file in the Emacs sources is ja-dic at 2.2MB,
> well below the current default for large-file-warning-threshold.
> So not warning about loading a 1/2GB file like in the initial report
> seems like a disservice.

I wouldn't worry before it got 10 times that, but that's me.

Don't forget that before that file was about to be read, it was
written by the previous Emacs session, which means that previous
session already had all that loaded, and took more memory than that
file's size.  If the user was not worried about their running Emacs's
footprint, why should we annoy them with questions at startup time?

IME, these measures are only useful when they prevent some very grave
problem, like Emacs crashing or becoming completely unresponsive.  (We
had such problems years ago, when the 64-bit build still had bugs with
using integer types that overflowed at INT_MAX, and we indeed had then
tests to prevent users from crossing that border.)  Otherwise, I
personally would prefer _not_ warning about large files and let each
user find the point where it becomes annoying to them.  This is
because IME that point is highly individual, and depends on both user
preferences and the resources on their machine.  We can never do as
well with a fixed threshold, even if its value is somehow calculated
from the available data: there are too many unknown factors here.

Again, just my $0.02.