improve BytesRefHash.sort performance by rearranging ids

[tyronecai]

Description

In https://github.com/apache/lucene/blob/main/lucene/core/src/java/org/apache/lucene/util/BytesRefHash.java#L179

with repeated calls to add and the final compact, the id in ids become randomly distributed. This means subsequent access to data in BytesRefBlockPool becomes more random.

This negatively impacts operations like computeCommonPrefixLengthAndBuildHistogram that require access to BytesRefBlockPool. Cache misses can be observed using the async-profiler tool.

Therefore, the order of IDs can be rearranged in compact, since ids stores the order in which items are added to BytesRefBlockPool, and this order is monotonically increasing.

This improves the continuity of data access and reduces cache misses.

I wrote a very simple piece of code:

https://github.com/tyronecai/LuceneBytesRefSortBench/blob/master/src/main/java/com/demo/BytesRefHashSortBech.java

This code retrieves a series of terms from a log file, adds them to BytesRefHash, sorts them, and observes the performance latency.

Ultimately, in a sorting test with millions terms, the performance improvement was approximately 20%.

Test Env

$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.5 LTS"

$ lscpu
Architecture:             x86_64
  CPU op-mode(s):         32-bit, 64-bit
  Address sizes:          48 bits physical, 48 bits virtual
  Byte Order:             Little Endian
CPU(s):                   8
  On-line CPU(s) list:    0-7
Vendor ID:                AuthenticAMD
  Model name:             AMD Ryzen 7 9700X 8-Core Processor

$ java -version
openjdk version "21.0.9" 2025-10-21 LTS
OpenJDK Runtime Environment (build 21.0.9+15-LTS)
OpenJDK 64-Bit Server VM (build 21.0.9+15-LTS, mixed mode, sharing)

Test on 200MB log file

java -jar bench-1.0-SNAPSHOT-jar-with-dependencies.jar /data/source/lucene-10.3.2/xxx.log 100 false
sort 2097152 unique terms in 118.03 ms

java -jar bench-1.0-SNAPSHOT-jar-with-dependencies.jar /data/source/lucene-10.3.2/xxx.log 100 true
sort 2097152 unique terms in 96.23 ms      (118.03 - 96.23) / 118.03  = 0.18

Test on some big log file

java -jar bench-1.0-SNAPSHOT-jar-with-dependencies.jar /data/source/lucene-10.3.2/xxx.txt 100 false
sort 33554432 unique terms in 4543.19 ms

java -jar bench-1.0-SNAPSHOT-jar-with-dependencies.jar /data/source/lucene-10.3.2/xxx.txt 100 true
sort 33554432 unique terms in 3385.94 ms    (4543.19 - 3385.94) / 4543.19 = 0.254

@mikemccand @dweiss Can you take a look here?

[dweiss]

This is brutally simple. I don't even remember why the compaction was so convoluted since we can't have any gaps and indeed the id sequence must be a simple range 0...size.

[dweiss]

Could you add a changes entry? Shall we apply this to 10x as well (so it should appear under 10.5 section).

[tyronecai]

Could you add a changes entry? Shall we apply this to 10x as well (so it should appear under 10.5 section).

done

1. modify the review title
2. add comment in compact()
3. add change entry

please take a look, thanks