Mark all as read

Does the location of an import statement affect performance in Python?


When writing Python-based apps (e.g. Django, Flask, etc.), it's often the case that import statements can be found all over the place, often more than once for the same module. For example, you can:

  • have the imports at the top of a module;
  • place the imports inside the functions where they're actually used;
  • end up importing the same module multiple times (e.g. both modules and have import math in it);

So, while you can place your import statements anywhere:

  1. is there a noticeable cost (e.g. memory, performance/speed, etc.) associated with a particular choice? And
  2. what's the "best practice" for module imports and why?
Why should this post be closed?


1 answer



The location within a module where an import statement is found by the interpreter is not expected to cause differences in performance such as speed or memory usage. Modules are singleton objects, which means that they're only ever loaded once and will not be re-imported or re-loaded again even if additional import statements are encountered.

Therefore, you should follow the best-practice of keeping import statements at the top of the module. All of that being said, how you do the import and/or subsequent attribute lookups, does have an impact.

Imports and Attribute Look-ups

Suppose you import math and then, every time you need to use the sin(...) function, you have to do math.sin(...). This will generally be slower than from math import sin and then using sin(...) directly because Python has to keep looking up the function name within the module every time an attempt to invoke it is made.

This lookup-penalty applies to everything that gets accessed using the dot . operator and will be particularly noticeable in a loop. It's therefore advisable to at least get a local reference to things you need to use/invoke frequently in performance critical sections.

For example, using the original import math example, right before a critical loop, you could do something like this:

# ... within some function
sin = math.sin
for i in range(0, REALLY_BIG_NUMBER):
    x = sin(i)   # faster than: x = math.sin(x)
    # ...

This is a trivial example, but note that something similar can happen with methods on other objects (e.g. lists, dictionaries, etc) because methods are still attributes that have to be looked up. (Remember, it's everything that requires using the dot . operator.)


Here're some benchmarks with 2 different CPUs.

This one is from an Intel Core i9 (8-CPUs: 4-Core + HT) I bought back in 2010:

>>> # with lookup
>>> timeit('for i in range(0, 10000): x = math.sin(i)', setup='import math', number=50000)

>>> # without lookup
>>> timeit('for i in range(0, 10000): x = sin(i)', setup='from math import sin', number=50000)

And the same tests repeated on an AMD Ryzen 9 3900X (24-CPUs: 12-Core + SMT) I bought earlier this year:

>>> # with lookup
>>> timeit('for i in range(0, 10000): x = math.sin(i)', setup='import math', number=50000)

>>> # without lookup
>>> timeit('for i in range(0, 10000): x = sin(i)', setup='from math import sin', number=50000)

There's a 10+ second difference in the look-up vs no look-up cases for both CPUs.

Note that the difference depends on how much time the program spends running this code, hence why the "performance critical section" qualifier is so important. The fact is that, for most (not all) other cases, the benchmarks above can be safely ignored because the actual impact of more sporadic usage will be negligible.

Where to Import and Why

The import statements should be kept at the top of the module, as it's normally done. Straying away from that pattern for no good reason is just going to make the code more difficult to go through. For example, module dependencies will be more difficult to find because import statements will be scattered throughout the code instead of being in a single easily-seen location. (You could say dependencies are "hidden".)

It may also make a module less reliable for clients and more error-prone for their own developers because it's easier to forget about dependencies. As a trivial example, suppose you have this in a module:

# ... lots of code above
def fn_j(x: int) -> float:
    import math
    return math.sin(x)
# lots of code below ...

Ok, that works. But then you add:

# ... lots of code above
def fn_z(x: int) -> float:
    # BUG: notice the missing, but required, duplicate `import math` here
    return math.cos(x)

Clients that call fn_j will be fine, but calling fn_z will run into a NameError: name 'math' is not defined, which is a very avoidable bug and no one wants that.

Ok ...

But you can catch this in your unit tests!

... I hear you think. Yes, you can, but that's beside the point.


Sign up to answer this question »