Trivial performance questions
Geoff Gerrietts
geoff at gerrietts.net
Fri Oct 17 12:49:27 EDT 2003
Quoting Brian Patterson (bp at computastore.com):
> I have noticed in the book of words that hasattr works by calling getattr
> and raising an exception if no such attribute exists. If I need the value
> in any case, am I better off using getattr within a try statement myself, or
> is there some clever implementation enhancement which makes this a bad idea?
>
> i.e. should I prefer:
> if hasattr(self,"datum"):
> datum=getattr("datum")
> else:
> datum=None
> self.datum=None
>
> over:
> try:
> datum=self.getattr("datum")
> except:
> self.datum=None
> datum=None
>
> The concept of deliberately raising an error is still foreign to
> this python newbie, but I really like the trapping facilities. I
> just worry about the performance implications and memory usage of
> such things, especially since I'm writing for Zope.
Generally prefer
d = getattr(self, "datum", None)
if d is None:
self.datum = None
This won't always result in the fastest code though. In particular,
there's a slight performance edge to be had if you're doing lots of
lookups (many tens of thousands) and you expect a low percentage
(single digit? is that too many?) to be None. Then try/except becomes
faster. If you think you're likely to be in this situation, it should
be pretty trivial to write some test cases to find the actual tradeoff
point.
> And while I'm here: Is there a difference in performance when checking:
> datum is None
> over:
> datum == None
Generally prefer the former, but the difference is likely to be masked
by other factors.
> and similarly:
> if x is None or y is None:
> or:
> if None in (x,y):
I've preferred the latter thinking it was less work on the
interpreter, under the general premise that the code for the "in"
operation was one swatch of C, while is / or / is was three different
swatches of C with "python internals" gluing them together. My
analysis is obviously pretty surface though.
> I appreciate that these are trivial in the extreme, but I seem to be
> writing dozens of them, and I may as well use the right one and
> squeeze what performance I can.
Maybe I'm a heretic, but I think this is a healthy attitude to have.
If you can write it optimally the first time with no significant
increase in effort, then nobody's going to hafta come back and rewrite
it later: that's a big maintenance win.
--G.
--
Geoff Gerrietts <geoff at gerrietts net>
"A man can't be too careful in the choice of his enemies." --Oscar Wilde
More information about the Python-list
mailing list