Prev: We Wait For Thee: char16_t, char32_t.
Next: Use of facet codecvt for indenting output text
From: Maxim Yegorushkin on 21 Jan 2010 09:15
On 16/01/10 19:26, Le Chaud Lapin wrote:

[]

>> Even so, I would believe that using "compare" instead of "less" would
>> be marginally better, and possible a premature optimization.
>
> On the contratry, "compare" can be nearly twice as fast as "less" in
> extreme cases. Imagine that the programmer has a set<> of 1,000,000
> Foo's:
>
> set<Foo>; // 1,000,000 elements
>
> If the test of relative order of two Foo's is inherently long, such
> that its excution time dominates the execution time of the other
> operations, say, in in AVL/Red-Black implementations (mainly
> rotations), then the "compare" method will be 1.9x, 1.95x, 1.98x, etc.
> as fast as as the "less" method.

Well, I mentioned in my post:

....
Interesting enough, using compare() (or compare<> functor) instead of
std::less<> in std::set/map<> would give it a speed boost for operations
like find() because to determine whether elements are equal it calls
std::less<> twice . That results in two strncmp() calls *while returning
from find()* when keys are strings, whereas using compare that would
require only one strncmp() call.
....

I.e. it makes one extra call to std::less<> on the return from find(),
rather than for each node.

--
Max

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

First  |  Prev  | 
Pages: 1 2 3 4 5 6 7 8 9 10
Prev: We Wait For Thee: char16_t, char32_t.
Next: Use of facet codecvt for indenting output text