2 ms·
> with additional runtime overhead Hate to be the optimization nerd, but that's not really how any of this works. It's likely that this overhead is two instruc
by lionkor 3y ago
> with additional runtime overhead
Hate to be the optimization nerd, but that's not really how any of this works. It's likely that this overhead is two instructions in the likely case (compare and jump), and there's absolutely no profiling being done here to show if this causes a measurable performance difference. It's quite likely that nobody here is profiling this, and is just guessing based on "more code = slower", but there is really no way to predict this in such a general sense. It may be that these bounds checks even cause the compiler to do optimizations later since it can make more assumptions.
At the same time, if performance turns out to he a problem, there is probably bigger fish to fry than removing guardrails (maybe memory layout, maybe access patterns, maybe reordering things.
- Kab1r 3y agoYou would be surprised how much impact the additional instructions can incur. I found UB in a dependency of a popular video encoder. My fix involved adding compare and branches. I thought it wouldn't be significant but then I was instructed to benchmark it and it was significantly slower.