Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Do more imported objects affect performance

Reply
Thread Tools

Do more imported objects affect performance

 
 
Filip Gruszczyński
Guest
Posts: n/a
 
      12-01-2008
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
 
Reply With Quote
 
 
 
 
Rafe
Guest
Posts: n/a
 
      12-01-2008
On Dec 1, 7:26*am, "Filip Gruszczyski" <(E-Mail Removed)> 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 Gruszczyski


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
 
Reply With Quote
 
 
 
 
Nick Craig-Wood
Guest
Posts: n/a
 
      12-02-2008
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 <(E-Mail Removed)>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 <(E-Mail Removed)> -- http://www.craig-wood.com/nick
 
Reply With Quote
 
Bruno Desthuilliers
Guest
Posts: n/a
 
      12-02-2008
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 <(E-Mail Removed)>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.

 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      12-02-2008
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
 
Reply With Quote
 
Steve Holden
Guest
Posts: n/a
 
      12-03-2008
Filip Gruszczyński wrote:
[something I moved to after Nick's reply, where it belongs]
> 2008/12/1 Nick Craig-Wood <(E-Mail Removed)>:
>> Rafe <(E-Mail Removed)> wrote:
>>> On Dec 1, 7:26?am, "Filip Gruszczy?ski" <(E-Mail Removed)> 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/

 
Reply With Quote
 
Nick Craig-Wood
Guest
Posts: n/a
 
      12-03-2008
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 <(E-Mail Removed)> -- http://www.craig-wood.com/nick
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Why do directly imported variables behave differently than thoseattached to imported module? Dun Peal Python 10 05-03-2011 10:11 PM
Does size of memory malloc'd affect performance? lancer6238@yahoo.com C Programming 7 09-29-2010 08:22 PM
How CPU Features Affect CPU Performance Ian Front Page News 0 02-18-2010 03:28 PM
Will this affect performance sjoshi Windows 64bit 3 10-26-2005 05:47 PM
"Variable ... is not imported..." using an imported variable from a module Volker Nicolai Perl Misc 9 07-04-2005 08:34 AM



Advertisments