Re: pdumper's performance

[Daniel Colascione]

> I was looking at the pdumper and one thing I was wondering is how to use
> of all the <foo>_marked_p and set_<foo>_marked functions impacts GC (and
> hence) runtime performance.
>
> I mean the fact that they're functions is perfectly fine, but the fact
> that they need to test pdumper_object_p might have a measurable impact,
> since I believe these operations are performed very many times per GC.

The cache line that holds that the dump region bounds ends up being very
hot, so testing it isn't really that expensive.

You can see for yourself whether there's an impact. Compile an Emacs with
support for both pdumper and unexec, dump it with unexec, and compare its
GC performance to Emacs built without support for pdumper and also dumped
with unexec.

As I recall, the difference is minimal.

Besides, you get performance back at the end: the dump region's mark bits
are stored contiguously and we can clear them very quickly at the end of
GC.

> Also I don't quite understand why this is needed: IIUC the markbits of
> pdump'd objects are stored elsewhere, but I don't understand why that
> needs to be the case.

Because we don't store dumped objects in blocks and so the calculations of
the normal locations of their mark bits would be wrong.