Performance regression starting in Lucene 10.1.0 (dis_max + constant_score)

[shimpeko]

Description

I observed a performance regression after upgrading Elasticsearch 8.19.8 (Lucene 9.12.3) to Elasticsearch 9.2.4 (Lucene 10.3.2). The slowdown appears for a query shape that uses dis_max + constant_score. I didn’t find any ES‑level changes that explain the regression, so I suspect Lucene.

After benchmarking performance of a query on multiple Lucene version, I confirmed a regression starting in Lucene 10.1.0.

Query shape

• dis_max (tie=0)
  • boost 25 * constant_score( OR of term queries on field1 + field2, minShouldMatch=1 )
  • boost 10 * constant_score( OR of term queries on field3, minShouldMatch=1 )

Reproducer

I created small standalone Lucene benchmark that reproduce performance regression: https://github.com/shimpeko/lucene-dismax-constantscore-benchmark

Benchmark result (Java 25.0.2, 5k docs, warmup 200, iters 1000)

• 9.12.3 -> 0.424 ms/iter
• 10.0.0 -> 0.439 ms/iter
• 10.1.0 -> 1.167 ms/iter
• 10.2.0 -> 1.312 ms/iter
• 10.2.1 -> 1.335 ms/iter
• 10.2.2 -> 1.345 ms/iter
• 10.3.0 -> 1.377 ms/iter
• 10.3.1 -> 1.335 ms/iter
• 10.3.2 -> 1.302 ms/iter

The regression starts at 10.1.0 and persists in later 10.x. There is also miner regression on 10.2.0

Version and environment details

Environment

• OS: macOS 26.2 (Build 25C56), Darwin 25.2.0
• CPU: Apple M1 Max (10 cores: 8 performance + 2 efficiency)
• RAM: 64 GB
• Java: 25.0.2 (OpenJDK)
• Lucene directory: ByteBuffersDirectory
• Analyzer: WhitespaceAnalyzer
  • Index: 5,000 docs, single segment (forceMerge(1))
  • Searcher: single‑threaded (no executor)

Notes

• In ES tests, similar query without constant_score or without dis_max did not show notable regress.

Let me know if you’d like additional data or a different reproduction setup.

[shimpeko]

The performance regression was introduced by commit c88f933.