Re: Enlarge MAX_ALLOCA?

[Stefan Monnier]

> Does anyone see problems with the change below, which raises the bar
> for 'alloca' to 64KB?  Are there any systems out there that we care
> about whose stack is so small as to make this dangerous?

It makes the potential max increment of stack space "per
lisp-eval-depth" larger, and hence increases the risk that we'll eat up
our stack before we bump into max-lisp-eval-depth.

The idea behind the 16KB limit is that the cost of malloc+free is likely
to be negligible compared the filling and using 16KB of data.

> 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.

I think it makes a lot of sense to try and allocate this space on the
stack when decoding file names, but why does it allocate such a huge
buffer just to en/decode a puny file name?

If the malloc/free done for this encode/decode is relatively costly,
maybe it's because we allocate too much space compared to what we use.


        Stefan