Re: Enlarge MAX_ALLOCA?

[Eli Zaretskii <eliz@gnu.org>]

> From: David Kastrup <dak@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 19 Jun 2014 19:04:09 +0200
> 
> >> If there is a hard limit due to short offsets or similar (and if
> >> there weren't, why bother at all?), then allocating a full 64kB
> >> might be a bad idea.
> >
> > Is there really such a system?  If so, which one?
> 
> Either your limit has a rationale in machine architectures or not.  If
> it has: the C standard guarantees that you are allowed to take the
> address _after_ an array.
> 
> The 68k architecture has short offsets (-32768..+32767) for addressing
> off an address register such as the stack pointer.

But we don't support 68k anymore, AFAIK.

> >> 64kB feels arbitrary.
> >
> > I explained my rationale for choosing this value.
> 
> The explanation was:
> 
> > Why 64KB?  Because that's the size of the work area coding.c allocates
> > whenever it needs to encode or decode something.  It turns out we do
> > this a lot, e.g., every redisplay calls file-readable-p on the icon
> > image files, which needs to encode the file name.  While the work area
> > is immediately free'd, I think allocating such a large buffer so much
> > has a potential of creating an unnecessary memory pressure on
> > 'malloc', and perhaps cause excess fragmentation and/or enlarge memory
> > footprint in some cases.
> 
> That's not related to an architecture restraint.  In fact, it merely
> follows the arbitrary definition
> 
> #define CHARBUF_SIZE 0x4000

Indeed.  As I stated.

> Arbitrary because this is not a lookup table size but a buffer size for
> portioned conversion.  Instead of doubling MAX_ALLOCA, it would seem to
> make more sense to reduce CHARBUF_SIZE to something making it fit better
> on the stack if this is performance relevant.

I don't think CHARBUF_SIZE is too arbitrary, but I will let the
experts explain why they chose it.

> As I said: there are architectural reasons (short addressing mode)
> making somewhat less than 32kB a good choice on some architectures.

But do we support such architectures?  I think we don't.