Re: Performance cost of GLIBCXX_ASSERTIONS?
* Jason Tibbitts:
>>>>> "TH" == Tom Hughes
<tom(a)compton.nu> writes:
TH> Presumably in this case the performance penalty was considered small
TH> enough that it was worth building even production code with this
TH> mode enabled.
I'd like to know if any performance analysis was done about this,
because the upstream of a package I help maintain (prusa-slicer) has
also indicated to me that they aren't in favor of compiling with
GLIBCXX_ASSERTIONS in code which is computationally expensive and not
security sensitive. (This after the assertion found an actual bug in
their code.) The only answer I could give was that any code
which can open downloaded files is "security sensitive" in some fashion,
and presumably the gcc/glibc developers have evaluated the performance
impact.
Is there any reference I could use to answer such questions?
For loops which use the correct type for the index type
(size_t/std::vector<T>::size_type), the bounds check is optimized away
by the compiler. There is one SPEC2006 regression, but it uses the
wrong index type:
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85929>
Such 32-bit/64-bit mismatches are often bugs anyway and easily fixed in
the source code. This case is difficult to optimize for the compiler
because by using the wrong type, the behavior of the code is different
for large arrays.
For non-sequential access, the compiler cannot optimize away the bounds
check. Whether the additional comparison is visible in profiles depends
on many, many factors. I haven't seen it show up so far.
Thanks,
Florian