@simulacrum as an experiment, or really, to keep myself occupied, I tried doing some manual bisection while cargo-bisect-rustc ran
and in the process of doing my own bisection, I had to run
rustup update ...
and I was a little surprised when it seemed like I was able to get the nightlies for my own bisection faster that way than
cargo-bisect-rustc was doing itself.
now to be fair, this was a totally not scientific test. I wasn't even doing the race on different computers, so the two ongoing processes were of course stealing time and network bandwidth from eachother
but I am still curious: Would you expect
cargo-bisect-rustc's download system to be significantly slower than that of
rustp? Does the manner in which
cargo-bisect-rustc is downloading its CI artifacts have some bottleneck I'm not aware of?
(hmm I just thought of one potential reason that my setup could be slowing things down... I was running
cargo-bisect-rustc inside of an Emacs shell, but my own bisection in a normal terminal. I know the Emacs shell can slow down interactive terminal stuff. I really should re-do the experiment outside of Emacs. That, and/or add a way to tell
cargo-bisect-rustc not to include the progress bars and whatnot.)
We use reqwest 0.9 (should probably update to async/await 0.10, I guess).
I think rustup uses curl, which might have better support for some features (e.g., maybe HTTP 3 or something crazy like that?)
but the terminal thing seems more likely
at least in theory bisect and rustup should be about on par
yeah I wont file an issue until i've gathered actual data
in a more scientific manner
one difference (though I hesitate to suggest it) is that rustup presumably has libcurl ... as the User-Agent
whereas we have something adhoc or nothing at all
so maybe Amazon (CloudFront) rate limits bisect as a result?
that'd be pretty sad