[Python-Dev] Comparison speed (original) (raw)

Martin v. Loewis martin@loewis.home.cs.tu-berlin.de
Tue, 15 May 2001 22:59:56 +0200

Of course. But except for instance objects, answering "does the type implement tprichcompare?" is one lousy pointer check

Almost - you also have to check the type flag.

and the answer will usually be-- provided we don't start stuffing code into every object's tprichcompare slot! --"no, so I can go to tpcompare immediately". Coercions and richcmps are the oddball cases today.

I'd like to add another data point, answering the question what types are most frequently compared. The first set of data is for running the Python testsuite.

riches 3040952 # Calls to PyType_RichCompare eqs 2828345 # Calls where the types are equal

String 2323122 Float 141507 Int 125187 Type 99477 Tuple 84503 Long 30325 Unicode 10782 Instance 9335 List 2997 None 383 Class 318 Complex 219 Dict 57 Array 49 WeakRef 34 Function 11 File 11 SRE_Pattern 10 CFunction 9 Lock 8 Module 1

So strings cover 82% of all the compare calls of equally-typed objects, followed by floats with 5%. Those calls together cover 93% of the richcompare calls.

Since this might give a blurred view of what is actually used in applications, I ran the PyXML testsuite with that python binary also. Leaving out types that are not used, I get

riches 88465 eqs 59279

String 48097 Int 5681 Type 3170 Tuple 760 List 492 Float 332 Instance 269 Unicode 243 None 225 SRE_Pattern 4 Long 3 Complex 3

The first observation here is that "only" 67% of the calls are with equally-typed objects. Of those, 80% are with strings, 9% with integers.

The last example is idle, where I just did an "import httplib", for fun.

riches 50923 eqs 49882

String 31198 Tuple 8312 Type 7978 Int 1456 None 600 SRE_Pattern 210 List 122 Instance 4 Float 1 Instance method 1

Roughly the same picture: 97% calls with equally-typed objects, of those 62% strings, 3% integers. Notice the 15% for tuples and types, each.

So to speed-up the common case clearly means to speed-up string comparisons. If I'd need to optimize anything else afterwards, I'd look into type objects - most likely, they are compared for EQ, which can be done nicely and directly in a tp_richcompare also.

Those two optimizations together would give a richcompare to 95% of the objects in the IDLE case.

Regards, Martin