* Jason Tibbitts: >>>>>> "TH" == Tom Hughes <tom@xxxxxxxxxx> 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
