On 08/20/2013 07:48 PM, Brian Anderson wrote:
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.
I tried reproducing the regression with a subset of the run-pass tests
earlier and failed, so tonight I tried harder by running all of make
check like `make check CFG_ENABLE_VALGRIND=1 RUST_THREADS=1` (after
previously building the compiler with `make`), and I did come up with a
slight regression: 75m before and 81m after. This still isn't close to
what the bots are showing though. The regression range I tested was
680eb71-15fca2d (covering the span on IRFY where the regression happened).
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
