[FRPythoneers] performance of cmp()

Jack Diederich jack at performancedrivers.com
Tue Sep 23 10:55:47 MDT 2003


On Tue, Sep 23, 2003 at 02:23:04PM +0530, Rahul Kumar wrote:
> I just finished writing my first python program. I have a performance
> critical loop in which 2 strings are compared. My initial code looked
> like this:
> 
> if a < b:
>   ...
> elsif a > b:
>   ...
> else:
>   ...
> 
> Knowing that 2 string comparisons are inefficient I found the cmp()
> method and did:
> 
> i = cmp(a,b)
> if i > 0:
>   ...
> elsif i < 0:
>   ...
> else:
>   ---
> 
> To my surprise the second version kept performing *slower* than the
> first. Why this (unexpected) behavior?

As a bonus the first version is also clearer than the second (IMO).

You have the additional overhead of having to lookup the 'cmp' builtin,
and the call overhead.  The fast C-based string-to-string compare[1] then
gets called under the covers in both cases. 

So the second version comparing two ints has the same weight as the
first version comparing two strings, but with all the cmp() call overhead.

Try this, it should be about the same speed as the second version.

dummy = min(0, 100)
if a < b:
 ...
elif a > b:
 ...
else:
 ...

Also, please post actual code when asking questions.  If there was
some other unobivous cycle-eater in your code we couldn't alert
you to it. The 'elsif' and '...' are flags that this isn't the
actual code that is giving you problems.

-jackdied

[1] It actually looks up the rich compare in the first object's
class struct (all in C) and calls it with the second string to
be compared.  This is fast because we're already looking at the
first object so we don't have any addtional name lookups or python
stack call overhead. bytecode isn't a perfect predictor of performance, 
but the first version should be much shorter than the second.




More information about the FRPythoneers mailing list