[
https://issues.apache.org/jira/browse/LUCENE-10531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529194#comment-17529194
]
Tomoko Uchida commented on LUCENE-10531:
It shouldn't be slow at least on a physical machine
[
https://issues.apache.org/jira/browse/LUCENE-10531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomoko Uchida updated LUCENE-10531:
---
Summary: Mark testLukeCanBeLaunched @Nightly test and make a dedicated
Github CI workflow
mocobeta commented on code in PR #846:
URL: https://github.com/apache/lucene/pull/846#discussion_r859684144
##
lucene/analysis/kuromoji/src/java/org/apache/lucene/analysis/ja/ViterbiNBest.java:
##
@@ -639,76 +622,35 @@ private void pruneAndRescore(int startPos, int endPos,
int
mocobeta commented on code in PR #846:
URL: https://github.com/apache/lucene/pull/846#discussion_r859684144
##
lucene/analysis/kuromoji/src/java/org/apache/lucene/analysis/ja/ViterbiNBest.java:
##
@@ -639,76 +622,35 @@ private void pruneAndRescore(int startPos, int endPos,
int
[
https://issues.apache.org/jira/browse/LUCENE-10542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529151#comment-17529151
]
Chris M. Hostetter commented on LUCENE-10542:
-
I don't think i had any comments (regarding
mocobeta commented on PR #805:
URL: https://github.com/apache/lucene/pull/805#issuecomment-654241
I looked closely at the code again and then found the n-best logic can be
separated from JapaneseTokenizer (not perfect though); opened a follow-up #846.
It's a safe change I think and I
Yuti-G commented on PR #843:
URL: https://github.com/apache/lucene/pull/843#issuecomment-641082
Hi @gsmiller, thanks for taking a look at my PR! Yes, I agreed that the
current behavior - sorting children(range in this case) by range values instead
of counts should be more preferred for
[
https://issues.apache.org/jira/browse/LUCENE-10292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529142#comment-17529142
]
ASF subversion and git services commented on LUCENE-10292:
--
Commit
[
https://issues.apache.org/jira/browse/LUCENE-10292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529140#comment-17529140
]
ASF subversion and git services commented on LUCENE-10292:
--
Commit
[
https://issues.apache.org/jira/browse/LUCENE-10292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529139#comment-17529139
]
Chris M. Hostetter commented on LUCENE-10292:
-
{quote}... how did you arrive at the
[
https://issues.apache.org/jira/browse/LUCENE-10274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529122#comment-17529122
]
Greg Miller commented on LUCENE-10274:
--
Exciting! I'll have a look at the PR in the next couple of
gautamworah96 commented on PR #848:
URL: https://github.com/apache/lucene/pull/848#issuecomment-572707
Hmm. I took a look at the error in the LUCENE-10529 JIRA and the delta seems
to be more than 1 (and this PR is setting it to `1f`?)
```
msokolov commented on code in PR #849:
URL: https://github.com/apache/lucene/pull/849#discussion_r860303468
##
lucene/facet/src/test/org/apache/lucene/facet/taxonomy/TestTaxonomyFacetAssociations.java:
##
@@ -142,6 +146,34 @@ public static void beforeClass() throws Exception {
gsmiller commented on PR #843:
URL: https://github.com/apache/lucene/pull/843#issuecomment-552499
I also suspect the current functionality is more useful for the majority of
use-cases than actually truncating by a top-n and sorting the ranges by their
counts. I imagine the order of
gsmiller commented on PR #843:
URL: https://github.com/apache/lucene/pull/843#issuecomment-546935
Interesting find. But this fix isn't really providing "top" children is it?
It's just providing the "first" N children right? Wouldn't we want to provide
the "top" ranges based on their
gsmiller opened a new pull request, #849:
URL: https://github.com/apache/lucene/pull/849
backport only
--
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,
mayya-sharipova commented on code in PR #842:
URL: https://github.com/apache/lucene/pull/842#discussion_r860262352
##
lucene/core/src/java/org/apache/lucene/index/FieldInfos.java:
##
@@ -178,7 +179,15 @@ public static FieldInfos getMergedFieldInfos(IndexReader
reader) {
msokolov commented on code in PR #844:
URL: https://github.com/apache/lucene/pull/844#discussion_r860260758
##
lucene/suggest/src/java/org/apache/lucene/search/suggest/fst/FSTCompletion.java:
##
@@ -184,110 +195,174 @@ public List lookup(CharSequence key, int
num) {
gsmiller commented on PR #848:
URL: https://github.com/apache/lucene/pull/848#issuecomment-484484
OK, shoot. Looks like this didn't quite work. Digging into the failing test.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to
[
https://issues.apache.org/jira/browse/LUCENE-10529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529049#comment-17529049
]
Greg Miller commented on LUCENE-10529:
--
I've got a PR up for this, but associated it with the dup
[
https://issues.apache.org/jira/browse/LUCENE-10530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529048#comment-17529048
]
Greg Miller commented on LUCENE-10530:
--
PR is up for this.
> TestTaxonomyFacetAssociations test
gsmiller opened a new pull request, #848:
URL: https://github.com/apache/lucene/pull/848
# Description
Fix floating point precision issues in TestTaxonomyFacetAssociations
# Solution
Ensure we sum the floats in the exact same order when determining our
"expected"
[
https://issues.apache.org/jira/browse/LUCENE-10530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529027#comment-17529027
]
Greg Miller commented on LUCENE-10530:
--
Instead of increasing the acceptable delta, I'd prefer to
[
https://issues.apache.org/jira/browse/LUCENE-10292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529018#comment-17529018
]
Dawid Weiss commented on LUCENE-10292:
--
I don't see any evidence in implementations of Lookup that
[
https://issues.apache.org/jira/browse/LUCENE-10542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529009#comment-17529009
]
Kevin Risden commented on LUCENE-10542:
---
[~hossman] I think I addressed your comments from
[
https://issues.apache.org/jira/browse/LUCENE-10292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528998#comment-17528998
]
Dawid Weiss commented on LUCENE-10292:
--
[~hossman] - don't know if you saw the recent discussion
[
https://issues.apache.org/jira/browse/LUCENE-10541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528991#comment-17528991
]
Dawid Weiss commented on LUCENE-10541:
--
I agree - we should fix mock analyzer to not return such
risdenk commented on PR #840:
URL: https://github.com/apache/lucene/pull/840#issuecomment-315776
Superseded by https://github.com/apache/lucene/pull/847
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL
risdenk commented on code in PR #847:
URL: https://github.com/apache/lucene/pull/847#discussion_r860101008
##
lucene/queries/src/java/org/apache/lucene/queries/function/valuesource/BytesRefFieldSource.java:
##
@@ -45,35 +45,33 @@ public FunctionValues getValues(Map
context,
[
https://issues.apache.org/jira/browse/LUCENE-10542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated LUCENE-10542:
--
Description:
While looking at LUCENE-10534, found that *FieldSource exists implementation
[
https://issues.apache.org/jira/browse/LUCENE-10542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated LUCENE-10542:
--
Status: Patch Available (was: Open)
> FieldSource exists implementation can avoid value
[
https://issues.apache.org/jira/browse/LUCENE-10542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated LUCENE-10542:
--
Description:
While looking at LUCENE-10534, found that *FieldSource exists implementation
[
https://issues.apache.org/jira/browse/LUCENE-10542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated LUCENE-10542:
--
Attachment: flamegraph_getValueForDoc.png
> FieldSource exists implementation can avoid
[
https://issues.apache.org/jira/browse/LUCENE-10542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated LUCENE-10542:
--
Description:
While looking at LUCENE-10534, found that *FieldSource exists implementation
[
https://issues.apache.org/jira/browse/LUCENE-10542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated LUCENE-10542:
--
Description:
While looking at LUCENE-10534, found that *FieldSource exists implementation
[
https://issues.apache.org/jira/browse/LUCENE-10534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528936#comment-17528936
]
Kevin Risden commented on LUCENE-10534:
---
I moved the FieldSource exists stuff here: LUCENE-10542
risdenk opened a new pull request, #847:
URL: https://github.com/apache/lucene/pull/847
# Description
Please provide a short description of the changes you're making with this
pull request.
# Solution
Please provide a short description of the approach taken to implement
Kevin Risden created LUCENE-10542:
-
Summary: FieldSource exists implementation can avoid value
retrieval
Key: LUCENE-10542
URL: https://issues.apache.org/jira/browse/LUCENE-10542
Project: Lucene -
risdenk closed pull request #840: LUCENE-10534: FieldSource exists improvements
URL: https://github.com/apache/lucene/pull/840
--
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.
[
https://issues.apache.org/jira/browse/LUCENE-10534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528931#comment-17528931
]
Kevin Risden commented on LUCENE-10534:
---
[~romseygeek] not sure I understand your question. I
[
https://issues.apache.org/jira/browse/LUCENE-10541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528913#comment-17528913
]
Michael McCandless commented on LUCENE-10541:
-
{quote}Let's fix the default. I know the
[
https://issues.apache.org/jira/browse/LUCENE-10541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528912#comment-17528912
]
Robert Muir commented on LUCENE-10541:
--
I think the problem is this line in MockTokenizer:
uschindler commented on PR #816:
URL: https://github.com/apache/lucene/pull/816#issuecomment-271174
Here is the map in thread:
https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/master/src/java.base/share/classes/java/lang/Thread.java#L178-L180
And this is how it is
Michael McCandless created LUCENE-10541:
---
Summary: What to do about massive terms in our Wikipedia EN
LineFileDocs?
Key: LUCENE-10541
URL: https://issues.apache.org/jira/browse/LUCENE-10541
uschindler commented on PR #816:
URL: https://github.com/apache/lucene/pull/816#issuecomment-262421
In short: ThreadLocals in Analyzers is ok, because even with many threads
(100.000 is no problem), because you have a map per thread pointing to few
analyzer's threadlocals with a weak
uschindler commented on PR #816:
URL: https://github.com/apache/lucene/pull/816#issuecomment-248678
> What is unclear is whether this is the reason why some users have been
seeing this threadlocal behavior, or if it's something that can generally
happen due to the fact that
rmuir commented on PR #816:
URL: https://github.com/apache/lucene/pull/816#issuecomment-241274
> Elasticsearch uses one unbounded threadpool
I do find it hilarious how casually you state this. Only in java, man :)
--
This is an automated message from the Apache Git Service.
To
rmuir commented on PR #816:
URL: https://github.com/apache/lucene/pull/816#issuecomment-240565
I do agree with removing any threadlocals on SegmentCoreReaders, if this is
somehow possible to do, without annoying people who bring back 10,000 search
results :)
But this is a very
jpountz commented on PR #816:
URL: https://github.com/apache/lucene/pull/816#issuecomment-221948
> IMHO, Elasticserach should use fixed size threadpools (there can be many
threads in it, the problem is huge pool that spawns new threads all the time
and discards them because they are
[
https://issues.apache.org/jira/browse/LUCENE-10538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuting Gan updated LUCENE-10538:
Description: When looking at the overridden implementation
getTopChildren(int topN, String dim,
wjp719 commented on PR #780:
URL: https://github.com/apache/lucene/pull/780#issuecomment-151403
I use es rally `httpLog` dataSet to compare the performance of this pr
data set
es rally httpLog
main operations
1. use ssd disk
1. add index sort `desc` of field
uschindler commented on PR #816:
URL: https://github.com/apache/lucene/pull/816#issuecomment-146277
> I want to see these servers make real effort to not use 10,000 threads.
Why does Elasticsearch need so many threads? They have a selector based
connection handling! And Solr is
uschindler commented on PR #816:
URL: https://github.com/apache/lucene/pull/816#issuecomment-142462
I agree with both of you:
- We should avoid ThreadLocal at places where it can be done in another way
(like for StoredFieldsReaders, it can just create a new one, escape analysis
will
vigyasharma commented on PR #633:
URL: https://github.com/apache/lucene/pull/633#issuecomment-110200
> I think it would be worth implementing the new MergePolicy method in
either MockRandomMergePolicy or AlcoholicMergePolicy or maybe both to exercise
concurrent addIndexes across any
[
https://issues.apache.org/jira/browse/LUCENE-10525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir resolved LUCENE-10525.
--
Fix Version/s: 9.2
Resolution: Fixed
Thanks you [~gworah]
> Improve WindowsFS
[
https://issues.apache.org/jira/browse/LUCENE-10525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528822#comment-17528822
]
ASF subversion and git services commented on LUCENE-10525:
--
Commit
[
https://issues.apache.org/jira/browse/LUCENE-10525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528821#comment-17528821
]
ASF subversion and git services commented on LUCENE-10525:
--
Commit
[
https://issues.apache.org/jira/browse/LUCENE-10525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528803#comment-17528803
]
ASF subversion and git services commented on LUCENE-10525:
--
Commit
[
https://issues.apache.org/jira/browse/LUCENE-10534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528802#comment-17528802
]
Alan Woodward commented on LUCENE-10534:
Is any of this solvable by moving to
rmuir merged PR #829:
URL: https://github.com/apache/lucene/pull/829
--
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:
[
https://issues.apache.org/jira/browse/LUCENE-10534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528798#comment-17528798
]
Kevin Risden edited comment on LUCENE-10534 at 4/27/22 1:48 PM:
Simple
[
https://issues.apache.org/jira/browse/LUCENE-10534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528798#comment-17528798
]
Kevin Risden commented on LUCENE-10534:
---
[https://github.com/risdenk/lucene-jmh]
Simple JMH
[
https://issues.apache.org/jira/browse/LUCENE-10534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528791#comment-17528791
]
Kevin Risden commented on LUCENE-10534:
---
{quote}although PR840 should probably have it's own
rmuir commented on PR #816:
URL: https://github.com/apache/lucene/pull/816#issuecomment-1110988180
The analyzers need to not be slow at query-time too. A threadlocal is a
reasonable datastructure to use, you see them in every programming language:
mocobeta commented on PR #846:
URL: https://github.com/apache/lucene/pull/846#issuecomment-1110967296
Passed all checks, and this is a safe refactoring that has no negative
effect, I think.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log
jpountz commented on PR #816:
URL: https://github.com/apache/lucene/pull/816#issuecomment-1110954677
Maybe another option would be to get rid of these threadlocals. We're
relying less on them than we used too, e.g. doc values readers are no longer
cached in threadlocals since we moved to
mocobeta commented on code in PR #846:
URL: https://github.com/apache/lucene/pull/846#discussion_r859684144
##
lucene/analysis/kuromoji/src/java/org/apache/lucene/analysis/ja/ViterbiNBest.java:
##
@@ -639,76 +622,35 @@ private void pruneAndRescore(int startPos, int endPos,
int
mocobeta opened a new pull request, #846:
URL: https://github.com/apache/lucene/pull/846
This is a follow-up of https://github.com/apache/lucene/pull/805 - NBest
logic can separate from Japanese-specific stuff, and reside in analysis-common.
This doesn't reduce code duplication but tries
uschindler commented on PR #816:
URL: https://github.com/apache/lucene/pull/816#issuecomment-1110778339
Something like:
```java
private final Lock readLock, writeLock;
CloseableThreadLocal#ctor() {
super();
var rwLock = new ReadWriteLock();
this readLock =
[
https://issues.apache.org/jira/browse/LUCENE-10508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528684#comment-17528684
]
ASF subversion and git services commented on LUCENE-10508:
--
Commit
[
https://issues.apache.org/jira/browse/LUCENE-10508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528682#comment-17528682
]
ASF subversion and git services commented on LUCENE-10508:
--
Commit
iverase merged PR #845:
URL: https://github.com/apache/lucene/pull/845
--
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:
uschindler commented on PR #816:
URL: https://github.com/apache/lucene/pull/816#issuecomment-1110769232
One suggestion: Use a `ReadWriteLock`
(https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/concurrent/locks/ReadWriteLock.html)
instead of synchronization around the
iverase opened a new pull request, #845:
URL: https://github.com/apache/lucene/pull/845
Follow up of https://github.com/apache/lucene/pull/824, we should use the
introduced MIN_WIDE_EXTENT for all wide rectangles.
--
This is an automated message from the Apache Git Service.
To respond to
jaisonbi commented on PR #816:
URL: https://github.com/apache/lucene/pull/816#issuecomment-1110760113
> Actually the implementation does not look wrong. I mostly like that it
removes the `ThreadLocal>`.
>
> The problem now is that every call goes through the WeakHashMap with a
lock
jaisonbi commented on PR #816:
URL: https://github.com/apache/lucene/pull/816#issuecomment-1110743533
> Stupid question: Why do you not open a bug report on OpenJDK? If this
ThreadLocal implementation is working better than the original one AND it
behaves exactly identical, why not ask
[
https://issues.apache.org/jira/browse/LUCENE-10519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528649#comment-17528649
]
Lucifer Boice edited comment on LUCENE-10519 at 4/27/22 8:42 AM:
-
We
[
https://issues.apache.org/jira/browse/LUCENE-10519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528649#comment-17528649
]
Lucifer Boice edited comment on LUCENE-10519 at 4/27/22 8:41 AM:
-
We
[
https://issues.apache.org/jira/browse/LUCENE-10519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528649#comment-17528649
]
Lucifer Boice commented on LUCENE-10519:
We have had the optimized version running on the real
Dawid Weiss created LUCENE-10540:
Summary: Remove alphabetically ordered completions from
FSTCompletion
Key: LUCENE-10540
URL: https://issues.apache.org/jira/browse/LUCENE-10540
Project: Lucene -
dweiss commented on code in PR #844:
URL: https://github.com/apache/lucene/pull/844#discussion_r859526919
##
lucene/suggest/src/test/org/apache/lucene/search/suggest/fst/TestFSTCompletion.java:
##
@@ -130,8 +153,17 @@ public void testAlphabeticWithWeights() throws Exception {
[
https://issues.apache.org/jira/browse/LUCENE-10470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ignacio Vera resolved LUCENE-10470.
---
Fix Version/s: 9.2
Assignee: Ignacio Vera
Resolution: Fixed
> Unable to
[
https://issues.apache.org/jira/browse/LUCENE-10470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528640#comment-17528640
]
ASF subversion and git services commented on LUCENE-10470:
--
Commit
[
https://issues.apache.org/jira/browse/LUCENE-10470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528637#comment-17528637
]
ASF subversion and git services commented on LUCENE-10470:
--
Commit
iverase merged PR #756:
URL: https://github.com/apache/lucene/pull/756
--
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:
[
https://issues.apache.org/jira/browse/LUCENE-10539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528635#comment-17528635
]
Dawid Weiss commented on LUCENE-10539:
--
PR is at: https://github.com/apache/lucene/pull/844
>
[
https://issues.apache.org/jira/browse/LUCENE-10539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss updated LUCENE-10539:
-
Fix Version/s: 9.2
> Return a stream of completions from FSTCompletion
>
[
https://issues.apache.org/jira/browse/LUCENE-10539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss updated LUCENE-10539:
-
Summary: Return a stream of completions from FSTCompletion (was: return a
stream of
Dawid Weiss created LUCENE-10539:
Summary: return a stream of completions from FSTCompletion
Key: LUCENE-10539
URL: https://issues.apache.org/jira/browse/LUCENE-10539
Project: Lucene - Core
uschindler commented on PR #816:
URL: https://github.com/apache/lucene/pull/816#issuecomment-1110698870
> That being said, I don't have real opposition to this patch, but I want us
to be careful about correctness. I am also concerned about not hurting the
performance of well-behaved apps
[
https://issues.apache.org/jira/browse/LUCENE-10519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528621#comment-17528621
]
Jaison.Bi commented on LUCENE-10519:
Thanks for the comment, [~sokolov] . I try to explain the
uschindler commented on code in PR #816:
URL: https://github.com/apache/lucene/pull/816#discussion_r859491311
##
lucene/core/src/test/org/apache/lucene/util/TestCloseableThreadLocal.java:
##
@@ -48,4 +49,67 @@ protected Object initialValue() {
return TEST_VALUE;
}
uschindler commented on PR #816:
URL: https://github.com/apache/lucene/pull/816#issuecomment-1110661444
Stupid question: Why do you not open a bug report on OpenJDK? If this
ThreadLocal implementation is working better than the original one AND it
behaves exactly identical, why not ask
[
https://issues.apache.org/jira/browse/LUCENE-10386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528596#comment-17528596
]
Dawid Weiss commented on LUCENE-10386:
--
Hi Petr.
So, I did have a look. TL;DR; version is that I
Yuti-G commented on PR #843:
URL: https://github.com/apache/lucene/pull/843#issuecomment-1110592769
Please see the benchmark results below:
```
TaskQPS baseline StdDevQPS candidate
StdDevPct diffp-value
95 matches
Mail list logo
