What do they add up to? You can turn overflow checks on in release mode with -C overflow-checks=on, so it feels like it should be really easy to benchmark the current impact. I couldn't find any benchmarks doing this, though.
I just did a very un-scientific benchmark to test this.
I chose ripgrep as a conservative choice, since most of the time should be I/O anyway.
I grepped for the word "Jesus" in a file that contained 100 copies of the king james bible (426MB of text). I ran it 100 times and averaged the results. Timed with /usr/bin/time.
--release without overflow checking was 0.0702 seconds on average.
--release with overflow checking was 0.0727 seconds, or about 3.5% slower
That's more than I expected for a program that's I/O bound.
> That's more than I expected for a program that's I/O bound.
Based on your description of your methodology and a reasonable assumption that you have more than ~426MB of available RAM, your benchmark is absolutely not I/O bound. Or at least, not bound by the speed of your disk. In your benchmark, your haystack is almost certainly entirely within memory and served from your operating system's page cache. It's unlikely you're hitting disk at all.
And even if you constructed your benchmark such that every search flushed your cache first and forced re-reading the file from disk, it may or may not be I/O bound. If your disk gives you 6 GB/s read speeds, you gotta do better than a traditional finite state machine to match that speed. (That is, probably SIMD.)
Very true! I wouldn't expect any blocking IO here (except for the first run). I would still expect the majority of the time be spent reading from memory vs CPU bound "number crunching".
I should have been clearer. In my day job we are latency sensitive and we'll refer to excessively hitting main memory as being IO bound.
Your query might be memory bound, but might not be. You've got to attain very high speeds to be memory bound. In your case, you chose a query that likely matches quite frequently, no? If so, it's certainly not going to be memory bound because of the overhead of dealing with all those matches.
Try a literal that doesn't match or matches very rarely and you'll have a better shot at being limited by memory bandwidth. (But still maybe not.)
You might consider trying a harder regex for a benchmark like this. The problem with 'Jesus' is that it's a simple literal and is basically the best case for a tool like ripgrep. It won't even touch the regex engine and will instead stay in highly optimized SIMD code that is unlikely to be impacted by whether overflow checks are enabled or not. (Because it's already optimized to produce good codegen.)
Try something like '\w+\s+\w+' instead. That will force the regex engine to run and you might see more impact from overflow checks. (But I'm just guessing.)
I'm sure it varies wildly by the type of program, and I'm sure much smarter people than me on the Rust team did their benchmarking homework when they originally made the choice. Just saying that to me, it seems like a reasonable default
It seems like a seriously wrong default for a language whose story is supposed to be safety. People wanting unsafe languages already have C and C++ for that :/.
To improve safety at large, Rust has to displace C++. People use C++ in part because of its speed (rightly or wrongly - but it is undeniably part of C++ culture). A language which is consistently slower than C++ will not displace C++. So, this was a point where the designers decided to hold their nose for now.
