You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "herley-shaori (via GitHub)" <gi...@apache.org> on 2026/03/14 22:39:52 UTC
[PR] Load lucene103 blocktree trie index on-heap to fix seekExact regression [lucene]
herley-shaori opened a new pull request, #15824:
URL: https://github.com/apache/lucene/pull/15824
## Summary
Fixes #15820
The lucene103 blocktree codec replaced the in-memory FST term index with an on-disk `TrieReader` backed by memory-mapped `RandomAccessInput`. Every `readLong`/`readByte` call on the mmap triggers Panama Foreign Memory API bounds checks (`MemorySessionImpl.checkValidStateRaw()`), causing a **~6x regression** in `seekExact` performance compared to the lucene90 FST which was always heap-resident.
This PR loads the trie index bytes into a heap-backed `ByteBuffersDataInput` at `TermsEnum` creation time in `FieldReader.newReader()`, so that trie navigation uses pure Java array reads instead of mmap reads.
### Why this works
- `ByteBuffersDataInput` backed by a single heap `ByteBuffer` takes the fast path: `blocks[0].getLong(blockOffset)` — a direct Java array read with no mmap or Panama bounds checks
- The trie index is typically small relative to the terms data, so heap overhead is minimal
- This matches the lucene90 behavior where the FST term index was always heap-resident
### Changes
- **`FieldReader.java`**: Modified `newReader()` to read the trie index slice into a `byte[]`, wrap it in `ByteBuffersDataInput`/`ByteBuffersIndexInput`, and pass the heap-backed input to `TrieReader`
- **`CHANGES.txt`**: Added optimization entry under Lucene 11.0.0
## Test plan
- [x] All existing blocktree tests pass (`TestTrie`, etc.)
- [x] All Lucene103/104 codec tests pass (869+ tests)
- [x] Code formatting verified via `./gradlew tidy`
- [ ] Benchmark seekExact throughput with UUID-based _id field across many segments to validate regression fix
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
Re: [PR] Load lucene103 blocktree trie index on-heap to fix seekExact regression [lucene]
Posted by "uschindler (via GitHub)" <gi...@apache.org>.
uschindler commented on PR #15824:
URL: https://github.com/apache/lucene/pull/15824#issuecomment-4067646391
-1 to merge this unless we know what the problem is. Please figure out why MemorySegments slows here, it is most likely some missing optimization in Hotspot.
ByteBuffers do exactly the same bounds checks, so it is unclear what exaytly the problem is.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
Re: [PR] Load lucene103 blocktree trie index on-heap to fix seekExact regression [lucene]
Posted by "mikemccand (via GitHub)" <gi...@apache.org>.
mikemccand commented on PR #15824:
URL: https://github.com/apache/lucene/pull/15824#issuecomment-4062856648
Thanks @herley-shaori -- that Panama per-byte bounds check is frustrating -- maybe @uschindler has an idea how to "elide" it?
I'm curious why we didn't detect this slowdown in Lucene's nightly benchmarks? It runs the `PKLookup` tasks which is exactly this "look up by primary key `id`" field usage: https://benchmarks.mikemccandless.com/PKLookup.html -- maybe that benchmark is missing something realistic since your/OpenSearch's usage was clearly (heavily!) affected?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
Re: [PR] Load lucene103 blocktree trie index on-heap to fix seekExact regression [lucene]
Posted by "herley-shaori (via GitHub)" <gi...@apache.org>.
herley-shaori closed pull request #15824: Load lucene103 blocktree trie index on-heap to fix seekExact regression
URL: https://github.com/apache/lucene/pull/15824
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
Re: [PR] Load lucene103 blocktree trie index on-heap to fix seekExact regression [lucene]
Posted by "rmuir (via GitHub)" <gi...@apache.org>.
rmuir commented on PR #15824:
URL: https://github.com/apache/lucene/pull/15824#issuecomment-4067649624
> * Each seekExact navigates the trie byte-by-byte: for a 36-byte UUID _id, that's up to 36 lookupChild() calls, each
> doing 2-4 RandomAccessInput.readLong() on mmap
Maybe this should be fixed first before shoving tons of lucene index data into jvm heap? Seems very inefficient/excessive
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
Re: [PR] Load lucene103 blocktree trie index on-heap to fix seekExact regression [lucene]
Posted by "uschindler (via GitHub)" <gi...@apache.org>.
uschindler commented on PR #15824:
URL: https://github.com/apache/lucene/pull/15824#issuecomment-4067823423
I think @gf2121 pointed it out in issue already: https://github.com/apache/lucene/issues/15820#issuecomment-4065638581
The problem is not on-heap vs off-hep. The problem here is also not the bounds check, it is obviouly a missing optimization in Panama that is required if the index is still open. With old MMapDirectoryy this was not done by the VM, risking to crash the VM when the file was closed.
Normally the check should be elided by Hotspot, butr for some reason it does not happen here. I assume the problem is that there are so many segments open at same time and maybe the check cannot be cached?
The bigger question here is: Why do we not see it for other loads of MememorySegmentIndexInput and only in this code path?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
Re: [PR] Load lucene103 blocktree trie index on-heap to fix seekExact regression [lucene]
Posted by "herley-shaori (via GitHub)" <gi...@apache.org>.
herley-shaori commented on PR #15824:
URL: https://github.com/apache/lucene/pull/15824#issuecomment-4067886406
Thanks for the thorough feedback; you're right on all counts, and I apologize for the incorrect assumptions.
Corrections:
- FST in Lucene 9.x was already off-heap (mmap) since LUCENE-9257, not heap-resident as I stated. The claim that
this "restores lucene90 FST behavior" was wrong.
- The ByteBuffersDataInput approach does the same bounds checks, so this doesn't actually solve the underlying
problem — it just shifts where the bounds check happens.
What I take away from the discussion:
1. The real question is why Hotspot fails to elide the Panama checkValidStateRaw() bounds check in the TrieReader
code path, specifically, when it does optimize it for other MemorySegmentIndexInput usages.
2. As @gf2121 suggested, testing TrieReader with ByteBuffer-based mmap (instead of Panama) would help isolate
whether Panama is the root cause.
3. As @rmuir pointed out, the per-byte trie traversal (up to 36 lookupChild() calls for a UUID string) is itself
excessive and should be addressed independently.
I'll close this PR. If I can help investigate the JIT optimization angle or the trie traversal efficiency, happy to
do so.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
Re: [PR] Load lucene103 blocktree trie index on-heap to fix seekExact regression [lucene]
Posted by "herley-shaori (via GitHub)" <gi...@apache.org>.
herley-shaori commented on PR #15824:
URL: https://github.com/apache/lucene/pull/15824#issuecomment-4068022099
> Can you please make clear which exact JVM version you are using while seeing the regression? Mike's benchamrks are on Java 25 already (Lucene main).
>
> There were some issues with the MemorySegmentSessionImpl that were solved in Java 24. I have the feeling that it might be a good idea to test with latest LTS release of JVM. Java 21 works with mmap, but is already "outdated".
>
> Uwe
My environment:
- JDK: Eclipse Temurin 25.0.2+10 (LTS)
- macOS (Apple Silicon)
What I did: I read the analysis in #15820 (which reports the regression on Amazon Corretto 21.0.8), explored the TrieReader/seekExact code path, and attempted a fix based on the assumption that loading the trie on-heap would avoid the mmap overhead. I did not independently reproduce or benchmark the regression ourselves.
What I got wrong: As you, @rmuir, and @gf2121 pointed out:
- FST in 9.x was already off-heap (mmap) since LUCENE-9257, not heap-resident
- ByteBuffersDataInput performs similar bounds checks, so the approach doesn't address the root cause
- The real question is why Hotspot fails to elide checkValidStateRaw() in this code path
On the JVM version question: The issue reporter uses Corretto 21.0.8. If Panama MemorySegmentSessionImpl optimizations landed in Java 24+, that could explain why Mike's Java 25 benchmarks show the trie as faster while the reporter sees a regression on Java 21. It would be worth asking the reporter to reproduce on Java 24 or 25 to confirm whether the issue is JVM-version-specific.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
Re: [PR] Load lucene103 blocktree trie index on-heap to fix seekExact regression [lucene]
Posted by "herley-shaori (via GitHub)" <gi...@apache.org>.
herley-shaori commented on PR #15824:
URL: https://github.com/apache/lucene/pull/15824#issuecomment-4064549985
> Thanks @herley-shaori -- that Panama per-byte bounds check is frustrating -- maybe @uschindler has an idea how to "elide" it?
>
> I'm curious why we didn't detect this slowdown in Lucene's nightly benchmarks? It runs the `PKLookup` tasks which is exactly this "look up by primary key `id`" field usage: https://benchmarks.mikemccandless.com/PKLookup.html -- maybe that benchmark is missing something realistic since your/OpenSearch's usage was clearly (heavily!) affected?
The discrepancy comes down to segment count. The nightly benchmark and the regression scenario exercise fundamentally different workload profiles:
**Nightly benchmark (PKLookup):**
- Uses a well-merged index (standard TieredMergePolicy)
- Likely has ~10-20 large segments after merging
- Each seekExact call traverses a small number of segments
- At low segment counts, the trie's compact on-disk format wins: fewer cache misses, smaller index footprint, and
the checkValidStateRaw() overhead per mmap read is amortized over fewer total calls
**Issue #15820 scenario (OpenSearch):**
- 32 KNN indices × 6 shards, refresh_interval=1s, continuous ingestion
- ~400 small segments per index (before merges catch up)
- Every indexed document with explicit _id triggers seekExact on **every segment** to check for version conflicts
- At 32 TPS × 20 docs/bulk × 400 segments = **~256,000** seekExact **calls/sec**
- Each seekExact navigates the trie byte-by-byte: for a 36-byte UUID _id, that's up to 36 lookupChild() calls, each
doing 2-4 RandomAccessInput.readLong() on mmap
- Total mmap reads: ~256K × ~36 × ~3 = **~27M mmap reads/sec**, each triggering MemorySessionImpl.checkValidStateRaw()
The cost model flips at high segment counts: total_overhead = segment_count × terms_per_doc × bytes_per_term ×
reads_per_node × checkValidStateRaw_cost. When segment count is low (benchmark), the constant factors of trie's compact format dominate. When segment count is high (real-world ingestion), the per-read mmap overhead dominates.
**Why heap loading is the right fix:**
- The trie index is typically small (much smaller than the terms data it indexes), so heap overhead is minimal
- This matches lucene90 FST behavior where the term index was always heap-resident
- ByteBuffersDataInput backed by a single heap ByteBuffer takes the fast path: blocks[0].getLong(blockOffset) — a
direct Java array read with no Panama bounds check
- It preserves the trie's structural advantages (compact format, simple navigation) while eliminating the mmap
overhead
**Benchmark suggestion:**
The current PKLookup benchmark may benefit from an additional variant that tests with a **high segment count** (e.g.,
200-500 small segments, NoMergePolicy, UUID-like random keys). This would catch regressions in the "many small
segments during active ingestion" workload, which is common in near-real-time search systems. The current
PerThreadPKLookup already sorts segments largest-first for early termination, but with many small segments of
similar size, this optimization doesn't help much.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
Re: [PR] Load lucene103 blocktree trie index on-heap to fix seekExact regression [lucene]
Posted by "mikemccand (via GitHub)" <gi...@apache.org>.
mikemccand commented on PR #15824:
URL: https://github.com/apache/lucene/pull/15824#issuecomment-4062862735
See `IH` here:
<img width="1680" height="742" alt="Screenshot 2026-03-15 at 8 05 36 AM" src="https://github.com/user-attachments/assets/0fd8da9f-a75d-4b86-a80d-379ab62399eb" />
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
Re: [PR] Load lucene103 blocktree trie index on-heap to fix seekExact regression [lucene]
Posted by "navneet1v (via GitHub)" <gi...@apache.org>.
navneet1v commented on PR #15824:
URL: https://github.com/apache/lucene/pull/15824#issuecomment-4072133239
> Can you please make clear which exact JVM version you are using while seeing the regression? Mike's benchamrks are on Java 25 already (Lucene main).
>
> There were some issues with the MemorySegmentSessionImpl that were solved in Java 24. I have the feeling that it might be a good idea to test with latest LTS release of JVM. Java 21 works with mmap, but is already "outdated".
>
> Uwe
@uschindler the JDK used was `JDK: Amazon Corretto 21.0.8`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
Re: [PR] Load lucene103 blocktree trie index on-heap to fix seekExact regression [lucene]
Posted by "uschindler (via GitHub)" <gi...@apache.org>.
uschindler commented on PR #15824:
URL: https://github.com/apache/lucene/pull/15824#issuecomment-4067946294
Can you please make clear which exact JVM version you are using while seeing the regression? Mike's benchamrks are on Java 25 already (Lucene main).
There were some issues with the MemorySegmentSessionImpl that were solved in Java 24. I have the feeling that it might be a good idea to test with latest LTS release of JVM. Java 21 works with mmap, but is already "outdated".
Uwe
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
Re: [PR] Load lucene103 blocktree trie index on-heap to fix seekExact regression [lucene]
Posted by "herley-shaori (via GitHub)" <gi...@apache.org>.
herley-shaori commented on PR #15824:
URL: https://github.com/apache/lucene/pull/15824#issuecomment-4068066208
> The other problem where this may come from: Are you seeing this with the shared arenas enabled or disabled? The check can only be elided, if you NOT reopen segments all the time. In Opensearch there were serious problems with your "index liveness checks", remember the issues where you run out of file handles/mappings, see #15054.
>
> The problem is whenever you close a file with a shared arena it causes a safepoint in the JVM, killing the optimizations in the top frame of all threads. So please make sure to use READ_ONCE for accessing metadata files in OpenSerach.
>
> In our benchmarks we do not see those issues, because the checks are correctly elided, unless you close files and not using the default arena grouping behavious of Lucene. Elasticserach does not see the problem and also not our own benchmarks.
>
> Can you possibly rerun a benchmark of your index with refresh of index disabled temporarily (so disabling NRT)?
Thanks for the detailed analysis. These are excellent questions, but I should be transparent — I'm not the original issue reporter, and I don't run the OpenSearch environment where the regression was observed. I explored the code path and attempted a fix based on the analysis in #15820, but I can't answer questions about OpenSearch's arena configuration, segment lifecycle, or liveness check behavior.
These questions about shared arenas, READ_ONCE for metadata files, and the NRT refresh interaction would be best directed at @navneet1v, @msfroh, and @jainankitk, who are closer to the OpenSearch side and can reproduce with the specific configurations you're asking about (shared vs non-shared arenas, refresh disabled, etc.).
The safepoint theory is very compelling, though — if frequent segment closes on shared arenas are causing safepoint storms that prevent Hotspot from eliding checkValidStateRaw(), that would explain both why the nightly benchmarks (stable segments, no NRT churn) don't see the issue and why the OpenSearch workload (400 segments, refresh_interval=1s, constant segment turnover) does.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
Re: [PR] Load lucene103 blocktree trie index on-heap to fix seekExact regression [lucene]
Posted by "navneet1v (via GitHub)" <gi...@apache.org>.
navneet1v commented on PR #15824:
URL: https://github.com/apache/lucene/pull/15824#issuecomment-4061581456
Thanks @herley-shaori for creating the fix.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
Re: [PR] Load lucene103 blocktree trie index on-heap to fix seekExact regression [lucene]
Posted by "rmuir (via GitHub)" <gi...@apache.org>.
rmuir commented on PR #15824:
URL: https://github.com/apache/lucene/pull/15824#issuecomment-4067757834
and please don't benchmark such "36-byte UUIDs" as that is not interesting. UUIDs are 128-bits by definition. Means 16 bytes. You can easily improve your performance by fixing this.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
Re: [PR] Load lucene103 blocktree trie index on-heap to fix seekExact regression [lucene]
Posted by "mikemccand (via GitHub)" <gi...@apache.org>.
mikemccand commented on PR #15824:
URL: https://github.com/apache/lucene/pull/15824#issuecomment-4062860209
Actually, there is an annotation (`IH`) for the cutover to trie BlockTree (you have to click+drag to zoom into the right region -- and it seems to show a performance win (~33% improvement). So now I'm really worried ... if our nightly benchy is silently steering us precisely opposite of "true north", that's horrifying!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
Re: [PR] Load lucene103 blocktree trie index on-heap to fix seekExact regression [lucene]
Posted by "uschindler (via GitHub)" <gi...@apache.org>.
uschindler commented on PR #15824:
URL: https://github.com/apache/lucene/pull/15824#issuecomment-4067838059
> This matches lucene90 FST behavior where the term index was always heap-resident
This is not true. In 9.x the terms index was also in mmap.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org
Re: [PR] Load lucene103 blocktree trie index on-heap to fix seekExact regression [lucene]
Posted by "uschindler (via GitHub)" <gi...@apache.org>.
uschindler commented on PR #15824:
URL: https://github.com/apache/lucene/pull/15824#issuecomment-4068005128
The othe rproblem where this may come from: Are you seeing this with the shared arenas enabled or disabled? The check can only be elided, if you NOT reopen segments all the time. In Opensearch there were serious problems with your "index liveness checks", remember the issues where you run out of file handles/mappings, see https://github.com/apache/lucene/issues/15054.
The problem is whenever you close a file with a shared arena it causes a safepoint in the JVM, killing the optimizations in the top frame of all threads. So please make sure to use READ_ONCE for accessing metadata files in OpenSerach.
In our benchmarks we do not see those issues, because the checks are correctly elided, unless you close files and not using the default arena grouping behavious of Lucene. Elasticserach does not see the problem and also not our own benchmarks.
Can you possibly rerun a benchmark of your index with refresh of index disabled temporarily (so disabling NRT)?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org