Re: Strange optimization results

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2011/4/11 Дмитрий Оксенчук:
>> 2011/4/11 Jonathan Wakely:
>>> The difference in performance may be caused by this overload of
>>> operator== for std::string
>>>
>>>  template<typename _CharT>
>>>    inline
>>>    typename __gnu_cxx::__enable_if<__is_char<_CharT>::__value, bool>::__type
>>>    operator==(const basic_string<_CharT>& __lhs,
>>>               const basic_string<_CharT>& __rhs)
>>>    { return (__lhs.size() == __rhs.size()
>>>              && !std::char_traits<_CharT>::compare(__lhs.data(), __rhs.data(),
>>>                                                    __lhs.size())); }
>>>
>>> If that's not declared then the default operator== simply calls
>>> string::compare and should have similar performance at all
>>> optimization levels.
>>
>> So to answer the original question, I'd say it's a feature, not a bug.
>>  operator== and string::compare are different so that operator== for
>> strings of different lengths will return false immediately.  Your
>> benchmark compares identical strings, so maybe checkingthe length
>> first isn't an optimization, but for many examples in real code it is
>> faster to avoid comparing every character in the string if the lengths
>> aren't the same.
>
> You are right, first overloaded operator== calls std::string::compare
> directly and there is no speed difference between them. Problem in
> optimization of second overloaded operator==. Without optimization it
> works faster than with -O2. I think this is a bug.

Maybe, but it might not be worth fixing.  Your microbenchmark is very
unrealistic.

Dmitry Gorbachev's test shows that maybe the string comparisons could
be moved outside the loop, which would greatly help when comparing the
same string objects 10 million times in a loop, as your original test
did.

But I don't think I've ever written a program which compares the same
two strings in a loop, so I'm not sure how important the optimization
is. When comparing to a different object in each loop iteration the
comparisons can't be moved out of the loop, and if the strings have a
common prefix but are not the same length then the operator== overload
which checks lengths can be significantly faster.



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux