On 08/20/2013 02:27 PM, Graydon Hoare wrote:
Hi,
We had a meeting today that was mostly about cycle time. Integrating a
change on the rust repo currently takes about 2 hours, which is still
far too much. We've tried approaching this from a variety of
perspectives in the past and I feel like possibly I've not conveyed the
cost and work breakdown, or discussed systematic approaches to the
problem yet. I'd like to do so now, as I believe the issues are all
quite solvable and I'd very much like people to shift their energy to
focus more on these matters:
Thanks, Graydon!
- On valgrind and non-valgrind alike, we're running subprocesses
inefficiently. This results in both too many threads (which
hurts valgrind especially badly) and too many blocking calls
(which hurts all platforms). I believe rewriting std::run to
use libuv will help significantly here. Alex is on this
but I imagine he can use help. See
https://github.com/mozilla/rust/pull/8645
A complete fix here is going to require uv-based process bindings, file
bindings, then an API for accessing stdin/out/err, so it will take a
while. Alex and Jefferey are both on various portions of this and we'll
try to get it done soon. I'm not sure though that this is causing the
valgrind regression on the bots - I tried all day to reproduce it and I
can't.
- Concerning metadata compression:
We could decompress using a different algorithm (or none at
all) and this might save us some time. But it's been tried
(see https://github.com/mozilla/rust/issues/6902) and wasn't
a huge win, and I think the larger win would be to change
algorithms to avoid reading the entire metadata segment.
I'd like to add some kind of --no-compress-metadata flag to rustc to
turn off compression, see what that buys. This is very low-hanging
fruit. Algorithmic changes to metadata reading are obviously more
important long-term, but ISTM that not compressing is just going to be
faster than compressing - no matter what else we do - so to get cycle
times down we will want that optimization. Is this ok?
If you have other ideas and areas of concern, or disagree or are unclear
on things I've mentioned in this email, please follow up.
Besides what I mentioned above I'll take another look at how the test
suite works and see if I can find any obvious improvements. After that
I'll circle back around and see if any of the other things you mentioned
are within my grasp.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
