[
https://issues.apache.org/jira/browse/SOLR-15428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17399324#comment-17399324
]
Uwe Schindler edited comment on SOLR-15428 at 8/15/21, 10:12 AM:
-----------------------------------------------------------------
Hi,
bq. I think if Uwe took to rebuilding/redesigning everything he was “not a big
fan of” he would quickly drown in the back log.
You misunderstood the "not a big fan of": I meant that I agree with you in that
regard, that having the configuration of plugins inside the project-local
build.grdle is also my personal preference. I am not a fan of the central
./gradle/something.gradle that contains a "if (module == XYZ)". But Dawid
already explained this (see above), I cannot add more information to his
explanation!
In my PR I just adapted your code to conform to this decission by Dawid. It was
not a "German cleanup" like the Policeman always does. It was response to kind
of a bug report on mailing list by [~mdrob]
bq. He simply doesn’t understand the story of those changes, given that any
sensible German would surely only have gotten to them via full consideration
and intention.
All fine, no worries, I was invoved in the Gradle stuff, so I understand the
history of Lucene/Solr Gradle. About the benchmark module: I am a big fan of
it, because I was always expecting to have something like this for Solr. So
many thanks for it! We can see this as an example to also rewrite Mike's
lucenebench which has problems with newer JVM and large fluctuations of results
caused by tiered compilation of hotpot, lambdas,...
I did not want to criticize your work. Last week [~mdrob] wrote a mail on the
mailing list that he found some "forbiddenapis" warnings and was a bit confused
because of it. The reason for that was that you did not disable the
fobiddenapis plugin, but just changed it to report all violations without
failing build. From that I interpreted that you just quickly ignored it, but
kept it online (otherwise "enabled=false" would have been the right choice), so
somebody else can make sure the bugs are fixed. And that's what I did. The JMH
stuff is well-known and there was already some issue on forbidden issue tracker
to add an "automatic exclusion" of generated classes. So the fix was just
appliying the exclude (I copypasted it from somewhere else). There was actually
only one forbiddenApis violation in the test case (incorrect use of new
Random()), which was fast to fix.
So Mark, I am not sure what you think I did do wrong. Sorry for interrupting
your discussion here, I just wanted to help. I also agreed to help with making
JMH compatible with ASF regulations because of GPL. I will stop doing this now.
was (Author: thetaphi):
Hi,
bq. I think if Uwe took to rebuilding/redesigning everything he was “not a big
fan of” he would quickly drown in the back log.
You misunderstood the "not a big fan of": I meant that I agree with you in that
regard, that having the configuration of plugins inside the project-local
build.grdle is also my personal preference. I am not a fan of the central
./gradle/something.gradle that contains a "if (module == XYZ)". But Dawid
already explained this (see above), I cannot add more information to his
explanation!
In my PR I just adapted your code to conform to this decission by Dawid. It was
not a "German cleanup" like the Policeman always does. It was response to kind
of a bug report on mailing list by [~mdrob]
bq. He simply doesn’t understand the story of those changes, given that any
sensible German would surely only have gotten to them via full consideration
and intention.
All fine, no worries, I was invoved in the Gradle stuff, so I understand the
history of Lucene/Solr Gradle. About the benchmark module: I am a big fan of
it, because I was always expecting to have something like this for Solr. So
many thanks for it! We can see this as an example to also rewrite Mike's
lucenebench which has problems with newer JVM and large fluctuations of results
caused by tiered compilation of hotpot, lambdas,...
I did not want to criticize your work. Last week [~mdrob] wrote a mail on the
mailing list that he found some "forbiddenapis" warnings and was a bit confused
because of it. The reason for that was that you did not disable the
fobiddenapis plugin, but just changed it to report all violations. From that I
interpreted that you just quickly ignored it, but kept it online (otherwise
"enabled=false" would have been the right choice), so somebody else can make
sure the bugs are fixed. And that's what I did. The JMH stuff is well-known and
there was already some issue on forbidden issue tracker to add an "automatic
exclusion" of generated classes. So the fix was just appliying the exclude (I
copypasted it from somewhere else). There was actually only one forbiddenApis
violation in the test case (incorrect use of new Random()), which was fast to
fix.
So Mark, I am not sure what you think I did do wrong. Sorry for interrupting
your discussion here, I just wanted to help. I also agreed to help with making
JMH compatible with ASF regulations because of GPL. I will stop doing this now.
> Integrate the OpenJDK JMH micro benchmark framework for micro benchmarks and
> performance comparisons and investigation.
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-15428
> URL: https://issues.apache.org/jira/browse/SOLR-15428
> Project: Solr
> Issue Type: New Feature
> Reporter: Mark Robert Miller
> Assignee: Mark Robert Miller
> Priority: Major
> Fix For: main (9.0)
>
> Attachments: bench.patch
>
> Time Spent: 9h 20m
> Remaining Estimate: 0h
>
> I’ve spent a fair amount of time over the years on work around integrating
> Lucene’s benchmark framework into Solr and while I’ve used this with
> additional local work off and on, JMH has become somewhat of a standard for
> micro benchmarks on the JVM. I have some work that provides an initial
> integration, allowing for more targeted micro benchmarks as well as more
> integration type benchmarking using JettySolrRunner.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
