GNU bug report logs -
#36597
27.0.50; rehash hash tables eagerly in pdumper
Previous Next
Reported by: Pip Cet <pipcet <at> gmail.com>
Date: Thu, 11 Jul 2019 14:07:02 UTC
Severity: normal
Tags: patch
Found in version 27.0.50
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#36597: 27.0.50; rehash hash tables eagerly in pdumper
which was filed against the emacs package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 36597 <at> debbugs.gnu.org.
--
36597: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=36597
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
[Message part 3 (text/plain, inline)]
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 (text/x-patch, attachment)]
[0002-src-fns.c-hash_table_rehash-Help-the-compiler-a-bit.patch (text/x-patch, attachment)]
[0003-src-pdumper.c-pdumper_load-XSETVECTOR-make_lisp_ptr.patch (text/x-patch, attachment)]
[0004-Don-t-needlessly-convert-to-unsigned-in-pdumper.patch (text/x-patch, attachment)]
[0005-In-pdumper-simplify-INT_MAX-computation.patch (text/x-patch, attachment)]
[0006-pdumper-speed-tweeks-for-hash-tables.patch (text/x-patch, attachment)]
[0007-pdumper-avoid-listing-hash-table-contents.patch (text/x-patch, attachment)]
[Message part 11 (message/rfc822, inline)]
[Message part 12 (text/plain, inline)]
This is a follow-up to bug#36447, which has been fixed.
Lazy rehashing for hash tables should be removed. This patch does that.
Lazy rehashing makes all code that accesses hash tables a little more
complicated; in at least one case, we forgot to do that, resulting in
bug#36596.
The sole benefit of lazy rehashing to be mentioned so far is that
start-up time is reduced a little (by less than a millisecond on this
system), and that for certain usage patterns (many short Emacs
sessions that don't do very much, I think), this might outweigh the
negative consequences of lazy rehashing.
Lazy rehashing means less maintainable code, more code, and, at
run-time, slightly slower code.
In particular, it means that we have to have a comment in lisp.h which
distracts from the code and has to be marked as "IMPORTANT!!!!!!!",
which I think is nearly as annoying as having to jump through special
hoops before accessing a hash table.
I'm posting this as a separate bug so we can have a, hopefully, brief
discussion about it and then either move away from lazy rehashing or
continue using it; if we decide to continue using it, it should be
documented in much more detail.
(We should keep in mind that conditional branches, even ones that are
well-predicted and don't cause cache misses, aren't free: they use
execution units, and preparing their arguments in registers increases
register pressure, and of course they increase code size.)
[0001-Rehash-hash-tables-eagerly-after-loading-a-portable-.patch (text/x-patch, attachment)]
This bug report was last modified 4 years and 284 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.