GNU bug report logs - #68244
hash-table improvements

Previous Next

Package: emacs;

Reported by: Mattias Engdegård <mattias.engdegard <at> gmail.com>

Date: Thu, 4 Jan 2024 16:29:02 UTC

Severity: wishlist

Full log


View this message in rfc822 format

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>,  68244 <at> debbugs.gnu.org
Subject: bug#68244: hash-table improvements
Date: Tue, 9 Jan 2024 13:51:24 -0800
Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:

> It's the hash-table's turn to be subjected to some performance
> tuning. The implementation has changed very little over the years and
> it's not so much a matter of a single big thing to fix as many small
> ones, so the list of changes is fairly long but ever little helps.
>
> A working patch series can be found in the scratch/hash-table-perf
> branch. Although it should all be satisfactory and an improvement on
> what was before, there are a couple of details that I'd like to do
> better, which is why this hasn't been merged yet: the way shared
> hash_table_test structs are cached isn't very elegant, nor is the way
> we deal with Qunbound in pdumper.c.

Thanks, these changes make sense to me both in terms of the performance
gains and the cleaner implementation.

The improved usability (de-emphasizing `hash-table-size', etc.) and
printed representation are certainly appreciated too.

Maybe lift `hash-table-rehash-size' and `hash-table-rehash-threshold' to
Lisp and mark them obsolete.  The hash table implementation is complex
enough for it to be worth avoiding cruft lying around.




This bug report was last modified 1 year and 146 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.