CODEWITHSUNDEEP
c++stringc++11boost
Ælex
Ælex

Reputation: 14869

Varying case-insensitive string comparisons performance

So, my phd project relies on a piece of software I've been building for nearly 3 years. It runs, its stable (It doesn't crash or throw exceptions) and I'm playing with the release version of it. And I've come to realise that there is a huge performance hit, because I'm relying too much on boost::iequals. I know, there's a lot of on SO about this, this is not a question on how to do it, but rather why is this happening. Consider the following:

#include <string.h>
#include <string>
#include <boost/algorithm/string.hpp>

void posix_str ( )
{
    std::string s1 = "Alexander";
    std::string s2 = "Pericles";
    std::cout << "POSIX strcasecmp: " << strcasecmp( s1.c_str(), s2.c_str() ) << std::endl;
}

void boost_str ( )
{
    std::string s1 = "Alexander";
    std::string s2 = "Pericles";
    std::cout << "boost::iequals: " << boost::iequals( s1, s2 ) << std::endl;
}

int main ( )
{
    posix_str();
    boost_str();
    return 0;
}

I put this through valgrind and cachegrind, and to my suprise, boost is 4 times slower than the native posix or the std (which appears to be using the same posix) methods. Four times, now that is a lot, even considering that C++ offers a nice safety net. Why is that? I would really like other people to run this, and explain to me, what makes such a performance hit. Is it all the allocations (seems to be from the caller map). I'm not dissing on boost, I love it and use it everywhere and anywhere. EDIT: This graph shows what I mean

Upvotes: 3

Views: 1558

Answers (1)

sbabbi
sbabbi

Reputation: 11191

Boost::iequals is locale-aware. As you can see from its definition here it takes an optional third parameter that is defaulted to a default-constructed std::locale, that represents the current global C++ locale, as set by std::locale::global.

This more or less means that the compiler has no way to know in advance which locale is going to be used, and that means that there will be an indirect call to a certain function to convert each character to lower-case in the current locale.

On the other hand, the documentation for strcasecmp states that:

In the POSIX locale, strcasecmp() and strncasecmp() shall behave as if the strings had been converted to lowercase and then a byte comparison performed. The results are unspecified in other locales.

That means that the locale is fixed, hence you can expect it to be heavily optimized.

Upvotes: 7

Related Questions