-
Notifications
You must be signed in to change notification settings - Fork 7.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A more robust JMH benchmarking set-up #963
Conversation
This looks awesome. I look forward to using this for all our perf testing. |
A more robust JMH benchmarking set-up
+1 |
Thanks! I'm a bit worried about the failing build, though. I don't think my changes should have caused those tests to fail. |
It doesn't look related. |
It looks like this change to build.gradle broke the Eclipse project import. Refreshing dependencies in Eclipse now loads the root project as a source folder and causes other dependency issues. Not yet sure why or how to fix it. |
Ah. What a shame :( I Admit to not having actually tested it in Eclipse. Works fine in Command Line and in IDEA. Would you kindly point out the steps to reproduce this? Eclipse and gradle plugin versions and such? |
I've reproduced it with multiple versions of Eclipse (Juno, Kepler, Luna) using the Gradle IDE plugin available in the Eclipse Marketplace. |
Version: Kepler Service Release 2 Gradle IDE 3.4.0.201310051517-RELEASE org.springsource.ide.eclipse.gradle.feature.feature.group GoPivotal, Inc. |
With the help of @quidryan I think we've got this solved. Pull request coming ... |
This is excellent ... thank you @gvsmirnov for your help on this! Is there a way to measure object allocation in the benchmarks? The best I've found is the HS_GC profiler, but it's not obvious how to use that to determine object allocations.
These two implementations should have very different object allocation characteristics. The time/throughput is basically the same, but one of them in our production environment works, the other causes GC pressure and intermittent problems. I'm trying to prove that with JMH so I can then test alternate implementations. |
I am unable to get the shadowJar functionality working:
|
- this allows running benchmarks - config is hardcoded right now - wasn't able to get uberjar/shadowjar functionality working (ReactiveX#963 (comment))
@benjchristensen Uh. #991 pretty much undid what I had done. One of the main points in using shadowJar was to avoid exactly what you see now: the params passed to JMH being hardcoded in the build script. So, what has happened here is alright for a temporary solution, just so it works in Eclipse, but we'll have to do it properly. I hope I can look into it this weekend. |
@benjchristensen what do you mean exactly by measuring object allocation? |
Which params are being hardcoded which weren't before? |
@quidryan Please see here: benjchristensen@ab7f408 There are two problems with using a
These two are sufficient to prefer packing everything into a single runnable jar "with batteries". |
Concerning args (which I didn't realize would part of JMH), we can pass in args, e.g gradlew benchmark -PjmhArgs="something" after adding this to the JavaExec configuration:
I'll defer to @benjchristensen to what the goal of the benchmarks are for, which is pertinent for #2. IIRC, it's primary purpose to compare the performance of a builds (via PRs). In which case, I'd imagine we'd want a static set of args to keep things standard across runs. If necessary to run on other hosts, then the shadow approach makes sense. Though I might recommend OneJar instead. |
Yes, I just made that change, it's pretty straight forward:
|
I want 3 things
|
I just merged #995 which allows custom args. I would still like a solution for generating the fat jar for execution away from Gradle. |
@gvsmirnov I would like to measure the impact on GC between two different class implementations and thus want to see things like number of objects allocated, pause times, young gen, time going to synchronization, etc. Here is the code being tested if it’s somehow relevant: SerializedObserver: https://github.com/Netflix/RxJava/blob/master/rxjava-core/src/main/java/rx/observers/SerializedObserver.java I’m testing with JMH and a custom test: JMH: The benchmark is here: https://github.com/Netflix/RxJava/blob/master/rxjava-core/src/perf/java/rx/operators/OperatorSerializePerf.java When I run this code in production we see GC issues when using I’m trying to use JMH to measure performance and memory impact. Interestingly, the JMH tests show Below are some of the results, including the HS_GC output. Tests run with https://github.com/Netflix/RxJava/blob/master/build.gradle#L81
|
The shadow jar is now being correctly created as of pull request: #996 I have confirmed that builds from command-line, importing into Eclipse, execution |
Usage:
For example:
See #776 for more details.