Subject: Re: bug#68244: hash-table improvements

From: Mattias Engdegård <[email-masked]>
Date: Fri, 5 Jan 2024 12:34:50 +0100

4 jan. 2024 kl. 18.45 skrev Eli Zaretskii <[email-masked]>:

> 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.

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.