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

[Paul Eggert]

On 8/10/20 6:04 AM, Lars Ingebrigtsen wrote:

> time make -j32 compile-always
> ...
> Er...  It's weird that there's so much difference in time between
> runs

I  think I get less variance if I do a sequential 'make' (i.e., without -j). Of 
course this takes longer.

> if we just take the mean
> from these numbers, it seems that your patch is making compilation
> faster.  :-)

It also simplifies the code a bit, so I took the liberty of installing it, after 
updating its commit message a bit and changing it to keep a comment that was 
updated recently (I figure this was a merge error). The patch I installed is the 
first patch attached. While reviewing the patch I noticed some relatively minor 
things in the neighborhood that could easily be fixed, so I did so by installing 
some followup patches, also attached (the last patch is the only one that's at 
all nontrivial). I'll mark the bug as done. Thanks to both of you for following 
up on this.

0001-Rehash-hash-tables-eagerly-after-loading-a-dump.patch
Description: Text Data

0002-src-fns.c-hash_table_rehash-Help-the-compiler-a-bit.patch
Description: Text Data

0003-src-pdumper.c-pdumper_load-XSETVECTOR-make_lisp_ptr.patch
Description: Text Data

0004-Don-t-needlessly-convert-to-unsigned-in-pdumper.patch
Description: Text Data

0005-In-pdumper-simplify-INT_MAX-computation.patch
Description: Text Data

0006-pdumper-speed-tweeks-for-hash-tables.patch
Description: Text Data

0007-pdumper-avoid-listing-hash-table-contents.patch
Description: Text Data