romseygeek commented on issue #11913:
URL: https://github.com/apache/lucene/issues/11913#issuecomment-1346186792
This isn't an area of the code I know well, but I think part of the problem
here is that the IndexWriter lifecycle is entirely under the management of the
PrimaryNode (e.g. calli
jpountz opened a new pull request, #12011:
URL: https://github.com/apache/lucene/pull/12011
When flushing segments that have an index sort configured, postings lists
get loaded into arrays and get reordered according to the index sort.
This reordering is implemented with `TimSorter`,
benwtrent commented on PR #12004:
URL: https://github.com/apache/lucene/pull/12004#issuecomment-1346600559
> Since we're changing this stuff, I wonder if BytesRef is the right
abstraction for a vector of bytes or if we should switch to a plain byte[]
I adjusted the query API there an
agorlenko commented on PR #11946:
URL: https://github.com/apache/lucene/pull/11946#issuecomment-1346767509
I've rewritten this PR with post-filtering approach, sorry for the delay.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitH
stefanvodita commented on code in PR #12010:
URL: https://github.com/apache/lucene/pull/12010#discussion_r1046013555
##
lucene/misc/src/test/org/apache/lucene/misc/search/TestDocValuesStatsCollector.java:
##
@@ -301,8 +301,8 @@ public void testDocsWithMultipleDoubleValues() thro
rmuir commented on code in PR #12010:
URL: https://github.com/apache/lucene/pull/12010#discussion_r1046028135
##
lucene/core/src/test/org/apache/lucene/codecs/lucene90/TestLucene90PointsFormat.java:
##
@@ -98,7 +98,8 @@ public void testMergeStability() throws Exception {
su
rmuir commented on PR #12010:
URL: https://github.com/apache/lucene/pull/12010#issuecomment-1346801373
thanks @stefanvodita for the suggested cleanups here!
--
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
mdmarshmallow commented on code in PR #11901:
URL: https://github.com/apache/lucene/pull/11901#discussion_r1046120980
##
lucene/facet/src/java/org/apache/lucene/facet/rangeonrange/RangeOnRangeFacetCounts.java:
##
@@ -0,0 +1,209 @@
+/*
+ * Licensed to the Apache Software Foundati
mdmarshmallow commented on code in PR #11901:
URL: https://github.com/apache/lucene/pull/11901#discussion_r1046128095
##
lucene/facet/src/java/org/apache/lucene/facet/rangeonrange/RangeOnRangeFacetCounts.java:
##
@@ -0,0 +1,209 @@
+/*
+ * Licensed to the Apache Software Foundati
mdmarshmallow commented on code in PR #11901:
URL: https://github.com/apache/lucene/pull/11901#discussion_r1046130284
##
lucene/facet/src/java/org/apache/lucene/facet/rangeonrange/LongRange.java:
##
@@ -0,0 +1,119 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under
mdmarshmallow commented on code in PR #11901:
URL: https://github.com/apache/lucene/pull/11901#discussion_r1046133836
##
lucene/facet/src/java/org/apache/lucene/facet/rangeonrange/LongRange.java:
##
@@ -0,0 +1,119 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under
mdmarshmallow commented on code in PR #11901:
URL: https://github.com/apache/lucene/pull/11901#discussion_r1046211359
##
lucene/facet/src/java/org/apache/lucene/facet/rangeonrange/LongRangeOnRangeFacetCounts.java:
##
@@ -0,0 +1,85 @@
+/*
+ * Licensed to the Apache Software Found
stevenschlansker commented on issue #11913:
URL: https://github.com/apache/lucene/issues/11913#issuecomment-1347017604
Letting PrimaryNode initialize the writer would work for us. It's in fact
pretty similar to the workaround we implemented to fix this in our application.
--
This is an au
rmuir opened a new issue, #12012:
URL: https://github.com/apache/lucene/issues/12012
### Description
I've probably hit this one several times recently. Probably only impacts ppl
not using IDEs :)
But I think it is just an ordering issue with the `gradle check`? It seems
to fir
rmuir commented on PR #12010:
URL: https://github.com/apache/lucene/pull/12010#issuecomment-1347152648
Thank you for reviewing @stefanvodita
--
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 s
dweiss commented on issue #12012:
URL: https://github.com/apache/lucene/issues/12012#issuecomment-1347320745
Enforcing the ordering here is quite trivial and makes sense to me. I'm not
sure what the impact is going to be - perhaps not too much given how much stuff
is going on elsewhere (in
dweiss commented on issue #12012:
URL: https://github.com/apache/lucene/issues/12012#issuecomment-1347348916
This seems to do the trick (a bit coarse to schedule after all javac tasks
but I'm not sure whether spotless cares about different source sets).
https://github.com/dweiss/luce
rmuir commented on issue #12012:
URL: https://github.com/apache/lucene/issues/12012#issuecomment-1347351739
i can test out timings of your patch on a fast mac m1: give me a few
minutes. I know it has enough concurrency to basically be bottlenecked by the
task dependencies... which I've look
gsmiller commented on code in PR #11901:
URL: https://github.com/apache/lucene/pull/11901#discussion_r1046413930
##
lucene/facet/src/java/org/apache/lucene/facet/rangeonrange/DoubleRangeOnRangeFacetCounts.java:
##
@@ -0,0 +1,94 @@
+/*
+ * Licensed to the Apache Software Foundati
rmuir commented on issue #12012:
URL: https://github.com/apache/lucene/issues/12012#issuecomment-1347377866
+1
Any difference is in the noise there:
```
Before: BUILD SUCCESSFUL in 3m 34s
After: BUILD SUCCESSFUL in 3m 24s
```
I did notice all the `spotlessJavaCheck`
rmuir commented on issue #12012:
URL: https://github.com/apache/lucene/issues/12012#issuecomment-1347394601
Hmm, @dweiss I think it is still not quite right. I think we are not slowing
down the `spotlessJava` task which is the one actually failing for me?
Here's a simple reproducer pa
rmuir commented on issue #12012:
URL: https://github.com/apache/lucene/issues/12012#issuecomment-1347398451
Here's my patch which seems to work and do the right thing. I'll benchmark
it. But also I don't know what i am doing with gradle:
```
diff --git a/gradle/validation/spotless.grad
vigyasharma opened a new pull request, #12013:
URL: https://github.com/apache/lucene/pull/12013
`UTF8TaxonomyWriterCache` keeps a ThreadLocal `BytesRefBuilder`, the bytes
for which, are not removed on thread close. This leads to memory leaks.
The change uses `CloseableThreadLocal` in
vigyasharma commented on issue #12000:
URL: https://github.com/apache/lucene/issues/12000#issuecomment-1347406654
> But one possibility to fix this cache is to replace the ThreadLocal with
CloseableThreadLocal, and close it out in close()
`DirectoryTaxonomyWriter` does call `cache.clo
rmuir commented on PR #12013:
URL: https://github.com/apache/lucene/pull/12013#issuecomment-1347422875
Thanks, it looks better to use `CloseableThreadLocal` than `ThreadLocal`...
but I don't understand what this "cache" is doing and why it actually documents
that it never frees memory. Espe
rmuir commented on issue #12012:
URL: https://github.com/apache/lucene/issues/12012#issuecomment-1347423692
I ran this patch on the mac m1 and also got `BUILD SUCCESSFUL in 3m 33s`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to Gi
rmuir commented on PR #12013:
URL: https://github.com/apache/lucene/pull/12013#issuecomment-1347439475
Also (summoning my inner @uschindler), curious what the perf impact is if we
simply remove these caches completely. Maybe they are not relevant to the
performance anymore due to faceting c
uschindler commented on PR #12013:
URL: https://github.com/apache/lucene/pull/12013#issuecomment-1347501489
Please remove the cache. Totally useless. It hurts more because the escape
analysis can't work.
When tiered compilation stepped in, this is just a useless extra
My rule: Neve
rmuir opened a new pull request, #12014:
URL: https://github.com/apache/lucene/pull/12014
When FMA is not supported by the hardware, these methods fall back to
`BigDecimal` usage [1] which causes them to be 2500x slower [2].
While most hardware in the last 10 years may have the suppor
gsmiller commented on PR #12014:
URL: https://github.com/apache/lucene/pull/12014#issuecomment-1347617300
+1, seems reasonable to me. We can always remove this ban in the future if
there's a good reason, but seems reasonable to put this in place to prevent it
sneaking in for now.
--
This
rmuir commented on PR #12014:
URL: https://github.com/apache/lucene/pull/12014#issuecomment-1347620183
Yeah, I think if the fallback java code was 2x, 4x, or 8x slower (like you
would expect from these intrinsics), we wouldn't be having this conversation :)
--
This is an automated messag
rmuir closed issue #12009: Find (and fix) places where we treat a long as a
double without an explicit cast
URL: https://github.com/apache/lucene/issues/12009
--
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
rmuir merged PR #12010:
URL: https://github.com/apache/lucene/pull/12010
--
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-unsubscr...@lucene.apach
dweiss commented on issue #12012:
URL: https://github.com/apache/lucene/issues/12012#issuecomment-1347844975
> I think we are not slowing down the spotlessJava task which is the one
actually failing for me?
Eh. I don't know what the relationships between those spotless tasks are.
Let
dweiss commented on issue #12012:
URL: https://github.com/apache/lucene/issues/12012#issuecomment-1347872711
I filed a PR #12015 . Indeed the 'core' formatting task seems to be named
'spotlessJava' (spotless + format name), the check and apply are just attached
to it in a fancy manner via s
dweiss merged PR #12015:
URL: https://github.com/apache/lucene/pull/12015
--
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-unsubscr...@lucene.apac
dweiss commented on issue #12012:
URL: https://github.com/apache/lucene/issues/12012#issuecomment-1347874082
I've applied the patch to 9x and main, btw.
--
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
37 matches
Mail list logo
