Re: Larger GC thresholds for non-interactive Emacs

[Stefan Monnier]

>> Obviously this process ends up with a very large one-step allocation
>> which is arguably interesting in itself (I suspect there's some
>> GC-inhibition going on there), but the more interesting point
>> is that with p=0.1 we get an amount of free space after GC
>> (i.e. blocks we can't release, because of fragmentation) that's about as
>> large as the next threshold, i.e. about 10%, whereas with p=1.0 this
>> amount of unreleasable free space is significantly higher.
> As far as I know, we never actually release back cons space to the OS
> anyway -- even if we could.

But we do release to the malloc library, which means it can be reused
for other things (instead of being constrained to only contain cons
cells, for example).   Whether that library in turn releases it back to
the OS is out of our control (and apparently current glibc never does
so).

>> I think p=1.0 (and the corresponding implication that we use up about
>> twice as much memory as the minimum we need) might be an acceptable
>> tradeoff (for batch use), but I don't think I'd be comfortable going
>> beyond that.
>
> Right.  We can still have the Emacs makefiles increase the threshold for
> build purposes even if we settle on a lower general level for --batch.

We could, I guess, tho the performance difference between p=1.0 and
p=2.0 isn't very significant.


        Stefan