GNU bug report logs - #68244
hash-table improvements

Previous Next

Full log

Message #17 received at 68244 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 68244 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#68244: hash-table improvements
Date: Fri, 5 Jan 2024 11:33:52 +0100

[ replies to questions asked elsewhere ]

4 jan. 2024 kl. 18.32 skrev Dmitry Gutov <dmitry <at> gutov.dev>:

>> +hash_table_alloc_bytes (ptrdiff_t nbytes)
>> +{
>> +  if (nbytes == 0)
>> +    return NULL;
>> +  tally_consing (nbytes);
>> +  return xmalloc (nbytes);
>> +}
> 
> Sorry if it's a stupid question, but if the operation doesn't add any Lisp "garbage", why increase the consing counter? That is likely triggers more GCs earlier which otherwise might not run, and if there are no slots to GC, it seems like they would run in vain.

That's a good question and it all comes down to how we interpret `consing_until_gc`. Here we take the view that it should encompass all parts of an allocation and this seems to be consistent with existing code.

These ancillary allocations are parts of the hash-table object: they are allocated and freed at the same time as the mother object, and subject to the same `consing_until_gc` accounting.

The new code is radically more efficient when growing tables, because we can free the old vectors immediately (and adjust consing_until_gc accordingly) instead of leaving it as garbage waiting to be collected. This provides several benefits in itself (GCs are made less often, we can re-use hot memory). Not having to traverse them in either the mark or sweep phases is another big gain (the key_and_value parts still have to be marked, of course).

> I'm curious whether any of these callers have tested with different values and found a difference in performance:
> 
> https://github.com/search?q=%3Arehash-threshold+language%3A%22Emacs+Lisp%22&type=code&l=Emacs+Lisp

I don't think they did, but it's easy to picture what was going on:

  Manual: Here is a Knob. It can be Turned to improve Performance.
  User:   Knob! Performance!

Some trials indicate that it's almost impossible for a user to use those knobs effectively, nor should they have to. Moreover, by removing them we not only give users fewer things to worry about, we are also able to improve performance for everyone.

Previous Next

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