-
Notifications
You must be signed in to change notification settings - Fork 13.4k
[jemalloc] set correct excess in alloc_excess #45512
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
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @aturon (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
412bc76
to
664e46e
Compare
664e46e
to
15dff15
Compare
@kennytm can you try this? |
@Mark-Simulacrum would it be possible to run a perf of this? |
@bors try |
[jemalloc] set correct excess in alloc_excess
☀️ Test successful - status-travis |
@Mark-Simulacrum do you have perf on this? |
Not yet -- I'll run it soon, haven't had a chance yet. @alexcrichton is probably busy with RBR, but if they might be able to get a chance to run it too. |
Is there actually anything in the standard library which uses this API? Additionally the handling of |
I don't know but we want to use it from RawVec in the future. Could you run perf?
That other place is |
In some tests, this results in an increased memory usage (3-5%) accompanied by a run-time reduction of 3-5%. In some other tests, this reduces the memory usage by 3-4%, slightly increasing the run-time (1%). In most cases, this change has no effect. @bluss what do you think? Maybe we could bench The only explanation I can think of is that initially, vectors have a larger capacity because of the usable size, but this capacity is not enough, so they double to a larger size that they would have done so without the usable size optimization. This produces the higher memory usage. However, they double fewer times than without this optimization, reducing the run-time. |
@gnzlbg I don't know the perf test suite very well, so I can't say if this tells us anything significant. And, allocator improvements should not be gated on improving rustc IMO, the allocator is more general purpose than that. (Meaning, the whole picture / other applications decide too) If I understand it correctly, we don't have any hard decisions in this PR? The excess methods are made for exposing the usable size, so it seems like a natural fix. |
I don't really know how to quantify these. I thought that was the whole point of the Does servo has "benchmark" tests or something that we could use? |
Currently perf is intended just for the rust compiler's own performance measurement, yes, though we eventually hope to expand that by adding runtime benchmarks as well. It just hasn't happened yet. |
No description provided.