On Tue, Aug 24, 2010 at 06:28:06PM -0400, David Malcolm wrote:
Profiling of a Fedora 14 "yum install *" showed it spending 80 seconds out of 274 within its implementation of "str_eq" (24 million calls), so optimizing this seems worthwhile.
One possibility is to hand-optimize this in C, or use Cython.
As a first step, attached are some more selftests for kitchen's [1] implementation of this function, to try to better capture some of the expected behavior.
I reworked these to use the standard data that's part of that particular test class and reorganized them to put the emphasis on bytes vs unicode instead of ascii vs non-ascii which just confuses things.
Thanks for organizing the matrix of what to test.
What's the expected behavior, if any, of passing in objects that aren't str or unicode?
e.g. passing in a float
str_eq(0.1, 0.1)
True
Is it acceptable if, say it, raises a TypeError instead?
Do you need support for objects that are derived from str/unicode as well as those specific classes?
I'm not sure what the expected behaviour for yum is. For the to_bytes and to_unicode kitchen code, this is configurable with the default being to return the simplerepr (basically, str but without throwing an error if there's a problem).
I'm not sure that's what we want to do here, though -- str_eq is not explicitly a converter between bytes and unicode. It's a test for equality. Two objects could return the same (or different) simplereprs and still be different (or the same). So TypeError seems like a better default. However, throwing a TypeError requires more isinstance calls which may be counter to your goal of speeding this up.
Right now, I'd say the behaviour of passing in non-basestring objects could be documented as undefined.
-Toshio