[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.
- bug#68244: hash-table improvements, (continued)
- bug#68244: hash-table improvements, Andy Moreton, 2024/01/16
- bug#68244: hash-table improvements, Andy Moreton, 2024/01/18
- bug#68244: hash-table improvements, Andy Moreton, 2024/01/20
- bug#68244: hash-table improvements, Basil L. Contovounesios, 2024/01/21
- bug#68244: hash-table improvements,
Mattias Engdegård <=
- bug#68244: hash-table improvements, Dmitry Gutov, 2024/01/05
- bug#68244: hash-table improvements, Mattias Engdegård, 2024/01/06
- bug#68244: hash-table improvements, Eli Zaretskii, 2024/01/06
- bug#68244: hash-table improvements, Dmitry Gutov, 2024/01/06
- bug#68244: hash-table improvements, Stefan Monnier, 2024/01/07
- bug#68244: hash-table improvements, Dmitry, 2024/01/07
- bug#68244: hash-table improvements, Mattias Engdegård, 2024/01/07
- bug#68244: hash-table improvements, Stefan Monnier, 2024/01/07
- bug#68244: hash-table improvements, Mattias Engdegård, 2024/01/08
- bug#68244: hash-table improvements, Stefan Monnier, 2024/01/08