[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Enlarge MAX_ALLOCA?
Re: Enlarge MAX_ALLOCA?
Thu, 19 Jun 2014 20:14:56 +0300
> From: David Kastrup <address@hidden>
> Cc: address@hidden
> 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.
Re: Enlarge MAX_ALLOCA?, Stefan Monnier, 2014/06/19
Re: Enlarge MAX_ALLOCA?, Dmitry Antipov, 2014/06/20
Re: Enlarge MAX_ALLOCA?, Eli Zaretskii, 2014/06/20
Re: Enlarge MAX_ALLOCA?, Andreas Schwab, 2014/06/20
Re: Enlarge MAX_ALLOCA?, David Kastrup, 2014/06/20