Peter Jaszkowiak

> We shouldn't do it in pre-main because Rust may not be in control of main, but that doesn't really matter, I would not really be in favor of doing...

Worst case would be if the haystack is highly repetitive and most of the pattern strings are very similar. Something like ```rust "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaab".find(&[ "aaaaaaaaaaaaaab", "aaaaaaaaaaaaaac", "aaaaaaaaaaaaaad", "aaaaaaaaaaaaaae", "z", // kills...

> I'd like to see some benchmarks for the impact this would have on proxy overhead. Like, even in the most optimistic scenario of spawning a different process that handles...

> If someone runs `cargo --version`, how much slower does that get? Okay, I'll start by measuring the overhead that's already added by the proxy. That will give a baseline...

I've measured the proxy latency by replacing the cargo proxy with a stub Rust program that just prints out the system time. I compare the system time from immediately before...

Adding a process spawn for an update check in the background appears to be insignificant, I wasn't able to measure a difference between that and the normal proxy latency. But...

> The check could run concurrently, taking its time and writing to disk so that the next cargo invocation can see that and display it to the user. Yes, there...

Your argument seems to only apply if the option is opt-out. If it was opt-in, would that be acceptable? What are your thoughts on having an extra question on install?...

> Sure, but anyone who wants this can set up a cron job to run `rustup update --check-only` at whatever interval they feel is desirable, so I don't really see...

IIRC string constants are always null terminated in the binary anyways.