bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#68244: hash-table improvements


From: Mattias Engdegård
Subject: 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@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.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]