Re: gnus, Maximum buffer size exceeded

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 31 Jul 2015 17:25:40 -0400
> 
> >> I wouldn't encourage people to use it: it increases the memory usage
> >> of Emacs (and hence slows it down by eating up your caches more
> >> quickly), but only increases the maximum buffer size by a fairly
> >> small amount.
> > 2GB vs 512MB doesn't sound like "fairly small amount" to me, more like
> > a factor of 4 and 1.5GB of absolute increment, not a small deal.
> 
> If you don't have a separate session just for this one file, or if you
> want to edit the file, or if the file will be font-locked, or in several
> other circumstances, the limit will be significantly smaller than 2GB.

Please explain how each one of those makes the limit significantly
smaller, because I don't see it.  The gap is very small compared to
2GB, so editing the file incurs a small penalty.  The other 2 issues I
don't see how they are involved at all.  Maybe we have bugs that
should be fixed, as we had in the 64-bit builds not so long ago.

> And since manually-created 500MB files are extremely rare, your 600MB
> might very well grow to 2.3GB tomorrow

It may well grow also beyond what the total VM on a typical 64-bit
machine is, so this problem is always present.  But as long as it
didn't grow, the user still has the advantage of being able to visit
files she couldn't before.  IOW, the risk of exceeding the limit
becomes lower as the limit goes up.

> so yes I consider the difference between 512MB and 2GB to be pretty
> small in this context: it's unlikely that --with-wide-int will
> satisfy all your needs if a standard build doesn't already satisfy
> them.

It doesn't need to satisfy all of them, just some.  You have limits on
a 64-bit machine as well, and they are not so much farther.  I don't
see how the situation there is qualitatively different.

> I'm not saying it's never useful, just that those cases where it's
> useful are rare.

Not for me, they aren't.