Questions about multiple import's.
Alex Martelli
aleaxit at yahoo.com
Fri Sep 8 03:24:59 EDT 2000
"Steve Juranich" <sjuranic at condor.ee.washington.edu> wrote in message
news:Pine.SOL.3.96.1000907171840.21405K-100000 at condor.ee.washington.edu...
[snip]
> I've read the docs on this, and it's still not entirely clear to me. In
one
> module, I've imported the re, os, and sys modules. Now in a parent
module,
> I will also need som funtionality from re, sys, and os. Does it severely
> hinder performance to re-import the 3 system modules into the parent
> namespace,
No. As import is something you do once at the start, in a substantial
application you only pay it as a startup cost, so it would not hinder
performance significantly even if it were a higher cost than it is.
> or should I just resolve myself to getting at the functions by
> tacking on an additional "name." construnction (e.g.,
> child.re.string.strip())?
Such multiple-levels references, albeit a minute cost, would be
more likely to be cost incurred in 'hot spots' (nested loops &c)
and so to hinder (not fatally but measurably) your performance.
In fact, one simple optimization that's worth applying to spots
you know to be hot is binding a reference to whatever you're
using in the nested-loop into a LOCAL variable first: e.g., change:
def hotStuff(n,flik):
for i in range(n):
for j in range(n):
fee.fie.foe.fum(i,j,flik)
into:
def hotStuff(n,flik):
istboae = fee.fie.foe.fum
for i in range(n):
for j in range(n):
istboae(i,j,flik)
This is not going to make a HUGE difference, but it will help
a little bit, as you pay the lookup cost once rather than N
squared times. The Python compiler clearly can't do this kind
of optimization for you -- for all it knows, each ...fum() call
could change, say, the fie field of global variable/module fee,
so it must repeat the lookup each time; this optimization can
be seen as letting Python [and the human reader] know what
you already do, i.e. that the _same_ function is going to be
called n-squared times, so, don't look it up every time...
Alex
More information about the Python-list
mailing list