[EXPERIMENT] Use AtomicSharedVector for token streams#159048
[EXPERIMENT] Use AtomicSharedVector for token streams#159048nnethercote wants to merge 4 commits into
AtomicSharedVector for token streams#159048Conversation
A slice is more general.
It currently doesn't include the length. It should. This change makes it more like other `StableHash` impls for vec-like types.
This comment has been minimized.
This comment has been minimized.
This adds a dependency on a new crate: `shared_vector`. It's done for efficiency: `AtomicSharedVector<T>` stores everything (strong refcount, len, capacity, and elements) in a single allocation, as opposed to `Arc<Vec<T>>` which requires two allocations. This also requires changing the `Vec<TokenTree>` argument of `TokenStream::new` to `shared_vector::Vector<TokenTree>`. Some of the changes are because the API is slightly different. There are also various `FIXME(shared_vector)` comments for places where `shared_vector` has suboptimal behaviour that might be improved in the future.
11eddbf to
500af70
Compare
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
[EXPERIMENT] Use `AtomicSharedVector` for token streams
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (68032ac): comparison URL. Overall result: ✅ improvements - no action neededBenchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf. @bors rollup=never Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -1.3%, secondary 1.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary 3.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 490.768s -> 491.381s (0.12%) |
|
icount results look great but the cycle results don't. |
|
Let's see if it wasn't noise. @bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
[EXPERIMENT] Use `AtomicSharedVector` for token streams
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (d19c964): comparison URL. Overall result: ✅ improvements - no action neededBenchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf. @bors rollup=never Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -1.5%, secondary 3.5%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 2.2%, secondary 3.3%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary 0.0%, secondary 0.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 490.017s -> 491.992s (0.40%) |
|
Much the same as the first run.
This makes sense, because it's very parser/token heavy. |
|
☔ The latest upstream changes (presumably #159293) made this pull request unmergeable. Please resolve the merge conflicts by rebasing. |
No description provided.