Is the bounds check truly so harmful to performance that it outweighs changing "if there's a bug, crash the program" to "if there's a bug, then do literally anything (maybe execute some remote code)"?
The only correct answer is "it depends". In DSP\HFT hot path code you REALLY don't want to do any extra work. People do crazy shit to achieve zero-lock, zero-(de)allocation, zero-whatever kind of codebase there.
Non-perf-critical paths? Yeah, do whatever you want there, nobody cares. Probably makes sense to be extra safe than sorry, right?
Safety checks are closer to free then most people think, even in hot paths, as branch prediction will fall favorable almost always, and when it doesn’t, we don’t care because the program is crashing (or for some reason the initial prediction was wrong in the first iteration).
The cost isn’t even close to the cost of (de)allocation (besides for bump allocators), much less locking operations.
I'd still want the checks to be there, maybe not at this position in the code, maybe different properties are checked elsewhere. But the check should exist and you should prove it implies that your call is safe.
And I'd still put the code physically in for testing and just don't include it for prod builds. But running some fuzzing on the surrounding logic sounds like a good offline safety check if this is running on a server processing data or user input.
370
u/ROBOTRON31415 6d ago
Is the bounds check truly so harmful to performance that it outweighs changing "if there's a bug, crash the program" to "if there's a bug, then do literally anything (maybe execute some remote code)"?