github-actions[bot] commented on PR #13740:
URL: https://github.com/apache/lucene/pull/13740#issuecomment-2365376489
This PR has not had activity in the past 2 weeks, labeling it as stale. If
the PR is waiting for review, notify the d...@lucene.apache.org list. Thank you
for your contributi
rmuir commented on PR #13816:
URL: https://github.com/apache/lucene/pull/13816#issuecomment-2365228413
this ID is generated for safety, and we only calculate this **once per
segment** when initially flushing it. Doesn't even happen at merge. Really, it
should be a few insns under lock, shou
original-brownbear commented on PR #13816:
URL: https://github.com/apache/lucene/pull/13816#issuecomment-2365187862
> profilers often lie about this
True but here I'd say whatever number the profiler outputs is only part of
the cost of hard synchronizing on a global like we do here (w
rmuir commented on PR #13816:
URL: https://github.com/apache/lucene/pull/13816#issuecomment-2365147464
profilers often lie about this. I think we should keep the synchronization
simple. the IDs are important to not duplicate.
--
This is an automated message from the Apache Git Service.
To
original-brownbear opened a new pull request, #13816:
URL: https://github.com/apache/lucene/pull/13816
Seeing this mutex contended up to O(10ms) in Elasticsearch at times. Moving
to CAS and removing the unnecessary alloction of a new instance for the
bitwise-and with the mask makes this per
scampi commented on issue #13103:
URL: https://github.com/apache/lucene/issues/13103#issuecomment-2365065510
In `OffsetsFromPositions` there is some logic to get offsets from positions.
https://github.com/apache/lucene/blob/53d1c2bd2fb3e6b9da590bee360996dbbdc8ea34/lucene/highlighter/s
