bug#68244: hash-table improvements

[Mattias Engdegård]

4 jan. 2024 kl. 18.45 skrev Eli Zaretskii <eliz@gnu.org>:

> It doesn't have to be a single number.  Showing a series of separate
> benchmarks is also fine.

Unfortunately it's not quite that simple: those numbers have to be interpreted 
and understood as well, which requires about as much work as making the 
benchmarks in the first place.

But let's try anyway: here is a run of one of the main suites I've been using. 
The numbers indicate relative changes in percent of elapsed time from the 
baseline to the tip of the scratch/hash-table-perf branch, negative numbers 
being better. For example, -50 means that speed has doubled, +100 that it has 
halved.

pct.org
Description: Binary data

Again, these are micro-benchmarks designed to amplify the signal in various 
respects, and the numbers don't tell everything -- far from it, in fact.

As mentioned before, one of the most important aspects of a data structure is 
not just how well it performs itself but how good neighbour it is: the less 
memory it uses and the better its locality of reference, the less negative 
impact it has on other objects and data structures. However, these effects can 
be difficult to measure correctly, so a lot of the tuning and assessment have 
to be done by indirect means.