bug#36597: 27.0.50; rehash hash tables eagerly in pdumper

[Pip Cet <pipcet@gmail.com>]

On Sun, Jul 14, 2019 at 2:40 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
> Although I like the simplicity of eager rehashing, I'm not yet sold on the
> performance implications. On my usual (cd lisp && make compile-always)
> benchmark, the patch hurt user+system CPU time performance by 1.5%. Admittedly
> just one benchmark, but still....

Indeed, that's plenty of small Emacs processes not doing very much.
It's not the case we ought to be optimizing for, I think, but the
performance concerns should be taken seriously. One way to avoid the
performance problems entirely is preferred-address loading of hash
dumps, but that has security implications...

> Also, must we expose Vpdumper_hash_tables to Lisp? Surely it'd be better to keep
> it private to pdumper.c.

Oops, I agree absolutely. Will remove that.

> I'll CC: to Daniel to see whether he has any insights about improvements in this
> area.

Sure; I sent the original email to Daniel, too, of course.

> PS. I ran that benchmark on my home desktop, an Intel Xeon E3-1225 v2 running
> Ubunto 18.04.2. To run it, I rebased your patch and also removed the
> no-longer-used PDUMPER_CHECK_REHASHING macro that my GCC complained about
> (wonder why that didn't happen for you?), resulting in the attached patch
> against current master 8ff09154a29a1151afb2902267ca35f89ebda73c.

Some GCC versions complain about it, some don't, I think.