diff options
author | Tim Peters <tim.peters@gmail.com> | 2001-05-10 21:45:19 (GMT) |
---|---|---|
committer | Tim Peters <tim.peters@gmail.com> | 2001-05-10 21:45:19 (GMT) |
commit | 4fa58bfac28fc08dbc928b48f3fe656dc59e0f6a (patch) | |
tree | 4c04f02f044a3fbabc11957baf4d9851326106f9 /Misc/setuid-prog.c | |
parent | 4c02fecf9c1f8a890b04ed3501aa68a636050e38 (diff) | |
download | cpython-4fa58bfac28fc08dbc928b48f3fe656dc59e0f6a.zip cpython-4fa58bfac28fc08dbc928b48f3fe656dc59e0f6a.tar.gz cpython-4fa58bfac28fc08dbc928b48f3fe656dc59e0f6a.tar.bz2 |
Restore dicts' tp_compare slot, and change dict_richcompare to say it
doesn't know how to do LE, LT, GE, GT. dict_richcompare can't do the
latter any faster than dict_compare can. More importantly, for
cmp(dict1, dict2), Python *first* tries rich compares with EQ, LT, and
GT one at a time, even if the tp_compare slot is defined, and
dict_richcompare called dict_compare for the latter two because
it couldn't do them itself. The result was a lot of wasted calls to
dict_compare. Now dict_richcompare gives up at once the times Python
calls it with LT and GT from try_rich_to_3way_compare(), and dict_compare
is called only once (when Python gets around to trying the tp_compare
slot).
Continued mystery: despite that this cut the number of calls to
dict_compare approximately in half in test_mutants.py, the latter still
runs amazingly slowly. Running under the debugger doesn't show excessive
activity in the dict comparison code anymore, so I'm guessing the culprit
is somewhere else -- but where? Perhaps in the element (key/value)
comparison code? We clearly spend a lot of time figuring out how to
compare things.
Diffstat (limited to 'Misc/setuid-prog.c')
0 files changed, 0 insertions, 0 deletions