-
Notifications
You must be signed in to change notification settings - Fork 13.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
Reduce allocations in the Task structure #11389
Comments
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Feb 14, 2014
The condition was the wrong direction and it also didn't take equality into account. Tests were added for both cases. For the small benchmark of `task::try(proc() {}).unwrap()`, this takes the iteration time on OSX from 15119 ns/iter to 6179 ns/iter (timed with RUST_THREADS=1) cc rust-lang#11389
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Feb 14, 2014
One of these is allocated for every task, trying to cut down on allocations cc rust-lang#11389
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Feb 14, 2014
Instead, use an enum to allow running both a procedure and sending the task result over a channel. I expect the common case to be sending on a channel (e.g. task::try), so don't require an extra allocation in the common case. cc rust-lang#11389
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Feb 14, 2014
Two unfortunate allocations were wrapping a proc() in a proc() with GreenTask::build_start_wrapper, and then boxing this proc in a ~proc() inside of Context::new(). Both of these allocations were a direct result from two conditions: 1. The Context::new() function has a nice api of taking a procedure argument to start up a new context with. This inherently required an allocation by build_start_wrapper because extra code needed to be run around the edges of a user-provided proc() for a new task. 2. The initial bootstrap code only understood how to pass one argument to the next function. By modifying the assembly and entry points to understand more than one argument, more information is passed through in registers instead of allocating a pointer-sized context. This is sadly where I end up throwing mips under a bus because I have no idea what's going on in the mips context switching code and don't know how to modify it. Closes rust-lang#7767 cc rust-lang#11389
So, today we get:
from:
and with another hello world task:
For a difference of exactly 0 mallocs! Do you have a testcase, @brson? |
Green threads are gone. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Spawning a green Task right now incurs untold numbers of allocations. It would be super nice to reduce this to ~1 allocation. Doing so will require a lot of trickery.
The text was updated successfully, but these errors were encountered: