bug#41194: 28.0.50; [feature/native-comp] fibn benchmark exhausts memory

[Andrea Corallo <akrl@sdf.org>]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> As detailed in bug#41077, I compiled the feature/native-comp branch[1]
> on a low-end-ish laptop[2], blacklisting char-fold.el since native
> compilation took too much memory for this file.
>
> As reported there, I get appreciable speedups on the benchmarks
> distributed in the elisp-benchmarks ELPA package, except for one
> specific test: fibn.  When native-compiled (with any value of
> comp-speed), this test makes Emacs abort with the message:
>
>> Memory exhausted--use C-x s then exit and restart Emacs
>
> I've plotted some graphs showing fibn's memory consumption for every
> value of comp-speed, as well as for emacs master[3] (where all 3
> iterations run to completion):
>
>
>
> See [4] for the methodology, source material and logs.  Out of curiosity
> I've disassembled the compiled functions in fibn.el for comp-speed 2;
> I'm not fluent enough in assembly to spot anything obviously wrong[5].
>
>
> Let me know if there are things you would like me to try out in order to
> investigate this.  

Hi Kevin,

sorry for the very late reply I just had a look.

The following is going on: being on 32bit system you get into bignums
end this allocates memory while is looping inside `elb-fibn'.
Unfortunatelly there's no opportunity of passing through maybe_gc to
trigger garbage collection because I've not implemented the equivalent
of what is the quitcounter in the byte interpreter.

I'll come-up with a patch to generate the equivalent code of the
quitcounter when compiling for speed < 3.

Thanks for the feedback

  Andrea

PS FYI I think memory consumption during compilation (as compile time)
should be now considerably lowered (but I've still haven't measured it).

-- 
akrl@sdf.org