-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Bazel performance regression caused by b321444 #9270
Comments
Thanks for the report @joeleba. I can think of either #8964 or 10db812#diff-15230e5dad94ffaefa7b526c0c1e89e5 that could cause performance regressions from java_tools. How can I reproduce this? Do you think this is a release blocker for bazel 1.0? |
To reproduce, you first need to clone the benchmarking tool: https://github.com/bazelbuild/bazel-bench.
The tool builds a bazel binary for each bazel commit, then performs |
Thanks! Is there a way I can point to my local bazel repository? And what's the difference between project_source and bazel_source? |
|
I think this is a release blocker for Bazel 1.0. cc @dslomov as the release manager to decide. |
I would like to understand what exactly caused the regression before making a call on 1.0 blocking |
I'm running the performance script. It takes a while. I'll post the findings when it's done. |
I did look at the action times in the JSON profile (on Mac). Some actions are faster, some are slower, but the sum of differences is amounts to ~250s compared to the faster build. Divided by the number of threads (12) this is roughly the slowdown that we see. I agree with Irina that #8964 is the most likely culprit. |
The script finished but it doesn't show me the results for all the commits I wanted. Here is the command I ran:
I actually wanted results for the last 2 commits I specified, which are my local commits using two different java_tools versions. Is there a way I can debug and see what went wrong? |
@joeleba helped me to debug the script and it doesn't work with branches other than master. I'll rebase into my local master and re-run the script. I hope we'll get results by the end of day. |
I managed to get some results \o/
|
There's a high pval for both commits. |
I think I should have compared them individually with a baseline. |
The commits are pushed here #9318 |
What is A high pval (0.99983) means there's strong evidence that there's a difference in the distribution of the wall time measured between So you can say that removing the Turbine update made Similarly, removing G1 and Turbine made Also note that running benchmarking locally brings about a certain degree of noise to the data, as it is not an isolated environment. |
|
Btw, with bazelbuild/bazel-bench#66, you can now specify pre-built bazel binaries to benchmark (as an alternative to the rebasing-your-local-change-onto-master workflow). Example:
|
That sounds great @joeleba! That should also make the script faster. Do you still need to specify |
In general:
In this case, you can use a combination of these 2 flags: Note that since bazelbuild/bazel-bench#66, if a commit is not available on |
Nice! Thanks for making these improvements! |
872c11a is the actual culprit. on a Mac (with 6 cores + HT):
on a beefy Linux workstation (with 36 cores + HT):
on my specialist workstation (restricting to 6 virtual cores):
|
Potential release blocker for 1.0 (#8573) |
*** Reason for rollback *** This change introduced a performance regression in bazel. More details in #9270. *** Original change description *** Allow G1 in tools/jdk/BUILD.java_tools. This is a followup to 01e6e05. (I think BUILD.java_tools was introduced in between the creation of the PR for 01e6e05 and its landing.) Closes #8964. PiperOrigin-RevId: 272156477
(Oh I see it is not complete yet...) |
@dslomov I'm starting a java_tools patch release. I'll let you know when the cherry pick is ready. |
thanks! |
*** Reason for rollback *** This change introduced a performance regression in bazel. More details in bazelbuild#9270. *** Original change description *** Allow G1 in tools/jdk/BUILD.java_tools. This is a followup to 01e6e05. (I think BUILD.java_tools was introduced in between the creation of the PR for 01e6e05 and its landing.) Closes bazelbuild#8964. PiperOrigin-RevId: 272156477
That's great, thanks for checking! |
Description of the problem / feature request:
The nightly benchmarking today showed a regression in MacOS env from commit e2a9e4a to 242acd6:
https://perf.bazel.build/bazel/2019/08/27_orig/report.html
After running the benchmarking again for the range of commits that potentially regressed Bazel performance, there's significant evidence to suggest that b321444 caused a regression of 4-7% when doing
build //src:bazel
:https://perf.bazel.build/bazel/2019/08/27/report.html
(it's clearest for Mac environment).
The run on buildkite: https://buildkite.com/bazel-trusted/bazel-bench-bisect/builds/1#9f5c44f7-4955-4bd5-a8e4-704e8a34ccc3
I've extracted the result tables here:
A high pval suggests strong statistical evidence that there's a regression. From the report seems like most of the increase in wall time comes from the Execution phase.
The text was updated successfully, but these errors were encountered: