GNU bug report logs - #68244
hash-table improvements

Previous Next

Full log

View this message in rfc822 format

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

[Message part 1 (text/plain, inline)]

4 jan. 2024 kl. 18.45 skrev Eli Zaretskii <eliz <at> 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 (application/octet-stream, attachment)]

[Message part 3 (text/plain, inline)]

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.

Previous Next

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