-
Notifications
You must be signed in to change notification settings - Fork 154
Add large-workspace
stress test benchmark
#2143
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
Conversation
I did a quick profile with Cachegrind. Here is the main part of a
It's definitely very different to other benchmarks, with lots of metadata stuff in there. But it's also pretty short running (0.13s, not much slower than helloworld at 0.09s). And the profile is still pretty flat, with only a few functions above 1%. Probably worth it for the variety, but I don't see that much scope for improving it. |
Perhaps introducing edges in a dep graph between |
Good suggestion. I had thought about increasing the number of crates (e.g. 500 to 1000) or the size of each crate (more than just three functions) but increasing dependencies might be more interesting. |
Right, so if some dependency is not direct in the final crate, rustc uses a different scheme to load the .rlibs, IIRC, so that could indeed be interesting. I'll modify the Python script to introduce some edges. |
df48f19
to
d23ce95
Compare
Changed the generation to work in several hierarchical levels, where crates depend on crates in the previous level. |
That definitely bumped it up some:
|
Might be interesting to take a look at this after the next LLVM bump, where (hopefully) |
<rustc_metadata::creader::CStore>::push_dependencies_in_postorder showed up in new benchmarks from rust-lang/rustc-perf#2143, hence I gave it a shot to remove an obvious O(n) there.
<rustc_metadata::creader::CStore>::push_dependencies_in_postorder showed up in new benchmarks from rust-lang/rustc-perf#2143, hence I gave it a shot to remove an obvious O(n) there.
…exset, r= cstore: Use IndexSet as backing store for postorder dependencies <rustc_metadata::creader::CStore>::push_dependencies_in_postorder showed up in new benchmarks from rust-lang/rustc-perf#2143, hence I gave it a shot to remove an obvious O(n) there. r? nnethercote
…exset, r=<try> cstore: Use IndexSet as backing store for postorder dependencies <rustc_metadata::creader::CStore>::push_dependencies_in_postorder showed up in new benchmarks from rust-lang/rustc-perf#2143, hence I gave it a shot to remove an obvious O(n) there. r? nnethercote
…exset, r=nnethercote cstore: Use IndexSet as backing store for postorder dependencies `<rustc_metadata::creader::CStore>::push_dependencies_in_postorder` showed up in new benchmarks from rust-lang/rustc-perf#2143, hence I gave it a shot to remove an obvious O(n) there. r? nnethercote
At RustWeek, I was talking to Zed developers (@osiewicz) about having something related to Zed in our benchmark suite, because it is apparently bottlenecked on loading incremental cache from disk and having a large number of workspace crates, which is not something that we have been benchmarking much in our suite so far.
I tried putting Zed directly into the suite, but that.. doesn't really work, as it has more than a thousand of dependencies, and just the preparation phase took almost an hour on a 8-core laptop (the current collector has 6 cores).
But that doesn't mean that we can't create stress tests that simulate what Zed (or other similar projects) do. I thought that one interesting case could be to have a large workspace, for which rustc has to locate and load all dependencies and then instantiate some code from them. Something that rust-lang/rust#132910 was trying to optimize.