Do more imported objects affect performance

Discussion in 'Python' started by Filip Gruszczyński, Dec 1, 2008.

  1. I have following question: if I use

    from module import *

    instead

    from module import Class

    am I affecting performance of my program? I believe, that all those
    names must be stored somewhere, when they are imported and then
    browsed when one of them is called. So am I putting a lot of "garbage"
    to this storage and make those searches longer?

    --
    Filip Gruszczyński
    Filip Gruszczyński, Dec 1, 2008
    #1
    1. Advertising

  2. Filip Gruszczyński

    Rafe Guest

    On Dec 1, 7:26 am, "Filip Gruszczyñski" <> wrote:
    > I have following question: if I use
    >
    > from module import *
    >
    > instead
    >
    > from module import Class
    >
    > am I affecting performance of my program? I believe, that all those
    > names must be stored somewhere, when they are imported and then
    > browsed when one of them is called. So am I putting a lot of "garbage"
    > to this storage and make those searches longer?
    >
    > --
    > Filip Gruszczyñski


    Why use it if you don't need it? Your post implies a choice and the
    '*' import can really make things muddy if it isn't actually necessary
    (rare). Why not just import the module and use what you need? It is
    way easier to read/debug and maintains the name-space.

    - Rafe
    Rafe, Dec 1, 2008
    #2
    1. Advertising

  3. On Tue, Dec 02, 2008 at 11:24:29AM +0600, Taskinoor Hasan wrote:
    > On Mon, Dec 1, 2008 at 8:21 PM, Filip Gruszczy?ski <>wrote:
    >
    > > I see. Thanks for a really good explanation, I like to know, how to do
    > > things in the proper way :)

    >
    > I always prefer to use import module and then use module.function. The
    > reason is simple. It makes the code more readable and maintainable.


    I prefer the "from module import function". That means that if
    "module" doesn't supply "function" it raises an exception at compile
    time, not run time when you try to run "module.function". It then
    becomes very easy to see which functions you use from any given module
    too. It is also very slightly faster but that isn't a major
    consideration.

    PEP 8 endorses this style somewhat

    http://www.python.org/dev/peps/pep-0008/ - see the Imports section.

    [...]

    it's okay to say this though:

    from subprocess import Popen, PIPE

    [...]

    When importing a class from a class-containing module, it's usually
    okay to spell this

    from myclass import MyClass
    from foo.bar.yourclass import YourClass

    If this spelling causes local name clashes, then spell them

    import myclass
    import foo.bar.yourclass

    and use "myclass.MyClass" and "foo.bar.yourclass.YourClass"

    Ultimately it is a matter of taste I think!
    --
    Nick Craig-Wood <> -- http://www.craig-wood.com/nick
    Nick Craig-Wood, Dec 2, 2008
    #3
  4. Nick Craig-Wood a écrit :
    > On Tue, Dec 02, 2008 at 11:24:29AM +0600, Taskinoor Hasan wrote:
    >> On Mon, Dec 1, 2008 at 8:21 PM, Filip Gruszczy?ski <>wrote:
    >>
    >>> I see. Thanks for a really good explanation, I like to know, how to do
    >>> things in the proper way :)

    >> I always prefer to use import module and then use module.function. The
    >> reason is simple. It makes the code more readable and maintainable.

    >
    > I prefer the "from module import function". That means that if
    > "module" doesn't supply "function" it raises an exception at compile
    > time, not run time when you try to run "module.function".


    Nope. import is an executable statement, and ImportError happens at
    runtime too.
    Bruno Desthuilliers, Dec 2, 2008
    #4
  5. On Tue, 02 Dec 2008 11:12:31 +0000, Nick Craig-Wood wrote:

    > I prefer the "from module import function". That means that if "module"
    > doesn't supply "function" it raises an exception at compile time, not
    > run time when you try to run "module.function".


    Wanna bet?


    >>> def spam():

    .... from math import harmonic_series
    .... return harmonic_series()
    ....
    >>> dis.dis(spam)

    2 0 LOAD_CONST 1 (-1)
    3 LOAD_CONST 2 (('harmonic_series',))
    6 IMPORT_NAME 0 (math)
    9 IMPORT_FROM 1 (harmonic_series)
    12 STORE_FAST 0 (harmonic_series)
    15 POP_TOP

    3 16 LOAD_FAST 0 (harmonic_series)
    19 CALL_FUNCTION 0
    22 RETURN_VALUE
    >>> spam()

    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "<stdin>", line 2, in spam
    ImportError: cannot import name harmonic_series


    The same thing happens if the from...import is at the top level of the
    module, except that compilation is immediately followed by execution.


    > It then becomes very
    > easy to see which functions you use from any given module too.


    If that's important to you. Personally, I find it more useful to know
    where a function is defined.


    --
    Steven
    Steven D'Aprano, Dec 2, 2008
    #5
  6. Filip Gruszczyński

    Steve Holden Guest

    Filip Gruszczyński wrote:
    [something I moved to after Nick's reply, where it belongs]
    > 2008/12/1 Nick Craig-Wood <>:
    >> Rafe <> wrote:
    >>> On Dec 1, 7:26?am, "Filip Gruszczy?ski" <> wrote:
    >>>> I have following question: if I use
    >>>>
    >>>> from module import *
    >>>>
    >>>> instead
    >>>>
    >>>> from module import Class
    >>>>
    >>>> am I affecting performance of my program? I believe, that all those
    >>>> names must be stored somewhere, when they are imported and then
    >>>> browsed when one of them is called. So am I putting a lot of "garbage"
    >>>> to this storage and make those searches longer?
    >>> Why use it if you don't need it? Your post implies a choice and the
    >>> '*' import can really make things muddy if it isn't actually necessary
    >>> (rare). Why not just import the module and use what you need? It is
    >>> way easier to read/debug and maintains the name-space.

    >> Importing the module is actualy slower... If you import the name into
    >> your namespace then there is only one lookup to do. If you import the
    >> module there are two.
    >>
    >> $ python -m timeit -s 'from timeit import Timer' 'Timer'
    >> 10000000 loops, best of 3: 0.0784 usec per loop
    >>
    >> $ python -m timeit -s 'import timeit' 'timeit.Timer'
    >> 1000000 loops, best of 3: 0.243 usec per loop
    >>
    >> I'm not suggestion you should ever use "from module import *" only
    >> ever import the things you actually need, eg
    >> "from module import MyClass, my_function"
    >>
    >> And here is the test again, actually calling something with the same
    >> difference in execution speed :-
    >>
    >> $ python -m timeit -s 'from os import nice' 'nice(0)'
    >> 1000000 loops, best of 3: 1.21 usec per loop
    >>
    >> $ python -m timeit -s 'import os' 'os.nice(0)'
    >> 1000000 loops, best of 3: 1.48 usec per loop
    >>

    > I see. Thanks for a really good explanation, I like to know, how to do
    > things in the proper way :)
    >

    Pardon me for intruding, but timings here are entirely the wrong focus
    for a Python newcomer. Given that imports are super-optimized (i.e. the
    code in the module is only performed once) such a small difference in
    timing is inconsequential, I would suggest.

    As long as "from module import *" is only ever used with modules
    specifically designed to support it, the other forms can be used as
    required. Sure, there is a timing difference between

    import module
    ...
    module.something()

    and

    from module import something
    ...
    something()

    but that's hardly the point. Learning to write sound Python is *much*
    more important that learning to write fast Python, and often the two
    coincide anyway.

    It was true when Kernighan and Plauger wrote it forty years ago and it's
    true now: "First, make it work. Then, *if it doesn't work fast enough*,
    make it work faster".

    regards
    Steve
    --
    Steve Holden +1 571 484 6266 +1 800 494 3119
    Holden Web LLC http://www.holdenweb.com/
    Steve Holden, Dec 3, 2008
    #6
  7. On Tue, Dec 02, 2008 at 10:53:47PM -0500, Steve Holden wrote:
    > Pardon me for intruding, but timings here are entirely the wrong focus
    > for a Python newcomer. Given that imports are super-optimized (i.e. the
    > code in the module is only performed once) such a small difference in
    > timing is inconsequential, I would suggest.
    >
    > As long as "from module import *" is only ever used with modules
    > specifically designed to support it, the other forms can be used as
    > required. Sure, there is a timing difference between
    >
    > import module
    > ...
    > module.something()
    >
    > and
    >
    > from module import something
    > ...
    > something()
    >
    > but that's hardly the point. Learning to write sound Python is *much*
    > more important that learning to write fast Python, and often the two
    > coincide anyway.
    >
    > It was true when Kernighan and Plauger wrote it forty years ago and it's
    > true now: "First, make it work. Then, *if it doesn't work fast enough*,
    > make it work faster".


    You are 100% right of course Steve. I was just trying to answer the
    specific question "which is faster" question which probably isn't
    helpful for new Python programmers to focus on.

    PS I enjoyed your book :)

    --
    Nick Craig-Wood <> -- http://www.craig-wood.com/nick
    Nick Craig-Wood, Dec 3, 2008
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Timasmith
    Replies:
    0
    Views:
    274
    Timasmith
    Nov 18, 2006
  2. Replies:
    7
    Views:
    762
    sfuerst
    Sep 29, 2010
  3. Dun Peal
    Replies:
    10
    Views:
    439
    Chris Rebert
    May 3, 2011
  4. Volker Nicolai
    Replies:
    9
    Views:
    896
    Fabian Pilkowski
    Jul 4, 2005
  5. Yan Huang
    Replies:
    3
    Views:
    92
    Thomas 'PointedEars' Lahn
    Oct 15, 2009
Loading...

Share This Page