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