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