Don't use Comparator.comparingDouble(...) in a hotish loop here, it
causes allocations that escape analysis is not able to remove.
=> lets just manually inline this to get predictable behavior and save
up to 0.5% of all allocations in some benchmark runs.
The value for the global count is incremented a lot more than it is
read, the space overhead of LongAdder seems irrelevant => lets use
LongAdder. The performance gain from using it is the higher the more
threads you use, but at 4 threads already very visible in benchmarks.
When an executor is provided to the IndexSearcher constructor, the searcher now executes tasks on the thread that invoked a search as well as its configured executor. Users should reduce the executor's thread-count by
1 to retain the previous level of parallelism. Moreover, it is now possible to start searches from the same executor that is configured in the IndexSearcher without risk of deadlocking. A separate executor for starting searches is no longer required.
Previously, a separate executor was required to prevent deadlock, and all the tasks were offloaded to it unconditionally, wasting resources in some scenarios due to unnecessary forking, and the caller thread having to wait for all tasks to be completed anyways. it can now actively contribute to the execution as well.
The backport of #13524 found a hole in the testing of `Lucene40BlockTreeTerms`
for versions before we moved metadata to its own file. This PR adds explicit bw
testing for this version. Adding the correct if/else statements made the code
extremely complicated so I opted for restoring the file as it was at the time
when we bumped the version.
This also fixes the bug that we introduced in #13524.
We don't need to clone the index input we hold on to in OffHeapFSTStore
since we only use it for slicing from known coordinates anyway.
-> remove the cloning and add the infrastructure to initialize
OffHeapFSTStore without seeking the input to the starting offset.
It is relatively easy to consume a massive amount of memory
for the minimize operation, with its lists of boxed Integer (even though these are mostly cached,
it's still more than 4b per instance to store them instead of plain storage) and neverending
duplicate+empty StateList instances.
The boxed integer situation we can fix and probably speedup by using the hppc primitive collections.
To fix the duplicate/empty StateList instances, we can use a constant. This requires some hacky forking
on the write path but that's about it.
This is partly motivated by ES users at times creating broken, very long prefix queries that can then eat up
GBs of heap. With this change, the examples I've been looking at become about 6x cheaper heap wise, making it
less likely that kind of mistakes impacts stability.
This includes the following changes:
- New `IndexInput#slice(String, long, long, ReadAdvice)` API that allows creating slices with different advices.
- `PosixNativeAccess` now explicitly sets `MADV_NORMAL` when called with `ReadAdvice.NORMAL`. This is required to be able to override a `RANDOM` advice of a compound file with a `NORMAL` advice of a sub file of this compound file.
- `PosixNativeAccess` now only ignores the first page if a range of bytes starts before the `MemorySegment` instead of the whole range.
The introduction of the doc values skip index in #13449 broke the backward codec test as those codecs do not support
it. This commit fix it by breaking up the base class for the tests.
Optional skip list on top of doc values which is exposed via the DocValuesSkipper abstraction. A new flag is
added to FieldType.java that configures whether to create a "skip index" for doc values.
Co-authored-by: Adrien Grand <jpountz@gmail.com>
Armin Braun
Christine Poerschke
zhouhui
Stefan Vodita
Benjamin Trent
Adrien Grand
Ignacio Vera
Zack Kendall
yadda yadda yadda
Dawid Weiss
Stéphane Campinas
Greg Miller
Michael Sokolov
Michael Sokolov
Pulkit Gupta
Bruno Roustant
Bruno Roustant
Stefan Vodita
Paul King
Hank Chang