Re: Merging scratch/no-purespace to remove unexec and purespace

[Pip Cet]

"Helmut Eller" <eller.helmut@gmail.com> writes:

> On Wed, Dec 18 2024, Helmut Eller wrote:
>
> [...]
>> So the pdumper copies objects from purespace to the dump like normal
>> objects; when loading the dump, purespace stays empty.
>>
>> I had (wrongly) assumed that the pdumper creates a separate section for
>> pure objects.  Creating such a section sounds easy enough (hmm, maybe
>> not so easy because of hashtables).  Still not sure if it would be worth
>> the effort.
>
> Out of curiosity, I implemented such a section with the attached patch.
> It seems that it would save ~2ms per collection cycle.

Very interesting, thank you for sharing!

I tried everything I could think of to disprove your findings, but while
I did find a minor optimization opportunity in the pdumper mark bits
code (a missing eassume (offset >= 0) / eassume (word_number >= 0)),
this affects both branches equally.  I can only conclude that your
observation is accurate, and we now have a number that is still close to
zero, but measurable.

The effect seems to be mostly constant (1-2 ms / GC cycle), but I did
see some slightly larger differences when more objects were on the heap.
Cache effects, probably (PURE_P doesn't have to wait for memory,
pdumper_marked_p_impl does).

(I did run into crashes when running emacs without --batch, but those
are easily fixed and did not affect the performance measurements at
all. I only mention this so that others running tests don't get their
hopes (or fears) up).

Pip