Our great sponsors
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
https://github.com/bheisler/criterion.rs is good for tests like that. It will give you much more than a single number and handle things like outliers. This makes identifying noisy tests simpler.
That's how WUFFS (Wrangling Untrusted File Formats Safely) works:
https://github.com/google/wuffs#what-does-compile-time-check...
> autovectorizing is broken by bounds checks
This is the big one. You pay a 50% penalty for actual CPU bound, iteration heavy code with bounds checking enabled.
https://github.com/matklad/bounds-check-cost
FWIW it looks like they're planning to kill it off for release builds: https://github.com/microsoft/STL/issues/277
In my experience with them, the performance hit is far more substantial that a few percent, except in situations where the compiler can elide the checks altogether. For example, simply iterating over std::vector with _ITERATOR_DEBUG_LEVEL=1 is twice as slow if you work with iterators explicitly instead of writing it as a range-for.
And I'm not sure if it can be substantially better, given that C++ as designed simply needs to do more checks to ensure validity - to catch cases like comparing iterators belonging to different containers, or iterators getting invalidated when containers get resized or when the corresponding element is deleted outright. This all can't be done with simple ranges or slices, which is why VC checked iterators maintain a reference to the parent container.