470,811 Members | 1,030 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,811 developers. It's quick & easy.

Class optimization at runtime

I would like to optimize my classes at run time. The question
is where to put my "if" statement.
-Inside __main__?
if option:
class Foo:
def __init__:
#do stuff
else:
class Foo:
def __init__:
#do other stuff
-Inside class definition?
class Foo:
if option:
def __init__:
#do stuff
else:
def __init__:
#do other stuff
-Inside each method definition?
class Foo:
def __init__:
if option:
#do stuff
else:
#do other stuff

Class instances will be created millions of times and the
method's on them called even more so whatever brings the most
speed will be used. I fear that the more readable way to do it
is also the slowest.

Thanks in advance,
-Brian
Jul 18 '05 #1
8 1342
Kind of hard to tell what you are trying to accomplish
but I'll try. Define the class with no if/else statements.
They only get parsed once. It is the "class instance"
creations that may get created millions of times. They
will be inside your logical structure.

class Foo:
def __init__(self):
# do stuff

class Bar:
def __init__(self):
# do stuff

if option: x=Foo()
else: x=Bar()

HTH,
Larry Bates
<br****@temple.edu> wrote in message
news:ma**************************************@pyth on.org...
I would like to optimize my classes at run time. The question
is where to put my "if" statement.
-Inside __main__?
if option:
class Foo:
def __init__:
#do stuff
else:
class Foo:
def __init__:
#do other stuff
-Inside class definition?
class Foo:
if option:
def __init__:
#do stuff
else:
def __init__:
#do other stuff
-Inside each method definition?
class Foo:
def __init__:
if option:
#do stuff
else:
#do other stuff

Class instances will be created millions of times and the
method's on them called even more so whatever brings the most
speed will be used. I fear that the more readable way to do it
is also the slowest.

Thanks in advance,
-Brian

Jul 18 '05 #2
Larry Bates wrote:
Kind of hard to tell what you are trying to accomplish
but I'll try. Define the class with no if/else statements.
They only get parsed once. It is the "class instance"
creations that may get created millions of times. They
will be inside your logical structure.
Yup.
class Foo:
def __init__(self):
# do stuff

class Bar:
def __init__(self):
# do stuff

if option: x=Foo()
else: x=Bar()


I don't see anything wrong with his original suggestion, provided that
makes the rest of the code simpler:
class Foo:
if option:
def __init__:
#do stuff
else:
def __init__:
#do other stuff


That 'if' also gets run only once - when the class is created.

Note that if your class instances only have a few instance variables,
the most effective optimization may be something quite else: To make
them subclasses of 'object', and define __slots__. A program of mine
ran in about half the time after doing so. There are a number of
dangers involved with __slots__, though. Check the reference manual.

For other optimization hints, see section 1.5 of the Python Programming
FAQ at <http://www.python.org/doc/faq/programming.html>.

--
Hallvard
Jul 18 '05 #3
On Mon, 2 Aug 2004 16:06:03 -0500,
"Larry Bates" <lb****@swamisoft.com> wrote:
Kind of hard to tell what you are trying to accomplish
but I'll try. Define the class with no if/else statements.
They only get parsed once. It is the "class instance"
creations that may get created millions of times. They
will be inside your logical structure. class Foo:
def __init__(self):
# do stuff class Bar:
def __init__(self):
# do stuff if option: x=Foo()
else: x=Bar()
Similarly:

class FooWithOption:
def __init__( self ):
# whatever

class FooWithoutOption:
def __init__( self ):
# whatever

if option:
Foo = FooWithOption
else:
Foo = FooWithoutOption

x = Foo( )

Alternatively:

module WithOption:
class Foo:
# whatever
class Bar:
# whatever

module WithOutOption:
class Foo:
# whatever
class Bar:
# whatever

if option:
from WithOption import *
else:
from WithoutOption import *

x = Foo( )

I guess it depends on how similar the with and without classes are as to
which one will be easier to maintain.

In either case, there's only one test and no additional overhead at
class instantiation time.
HTH,
Larry Bates


Regards,
Dan

--
Dan Sommers
<http://www.tombstonezero.net/dan/>
Never play leapfrog with a unicorn.
Jul 18 '05 #4
Dan Sommers wrote:
Alternatively:

module WithOption:
class Foo:
# whatever
class Bar:
# whatever

module WithOutOption:
class Foo:
# whatever
class Bar:
# whatever

if option:
from WithOption import *
else:
from WithoutOption import *

x = Foo( )


Or even better:

if option:
import WithOption as FooModule
else:
import WithoutOption as FooModule

x = FooModule.Foo( )

(I twitch every time I see 'from X import *' ...)

Jeff Shannon
Technician/Programmer
Credit International

Jul 18 '05 #5
Jeff Shannon wrote:
Or even better:

if option:
import WithOption as FooModule
else:
import WithoutOption as FooModule

x = FooModule.Foo( )

(I twitch every time I see 'from X import *' ...)


That, and mixed-case module names -- and no, I'm not advertising
all-uppercase here...

Peter
Jul 18 '05 #6
On Tue, 03 Aug 2004 23:46:32 +0200,
Peter Otten <__*******@web.de> wrote:
Jeff Shannon wrote:
Or even better:

if option:
import WithOption as FooModule
else:
import WithoutOption as FooModule

x = FooModule.Foo( )

(I twitch every time I see 'from X import *' ...)

Yep, you're right. I always forget about the "as" option.
That, and mixed-case module names -- and no, I'm not advertising
all-uppercase here...


My mistake again. The names I chose were for illustrative and
explicative purposes only; nothing else was (meant to be) implied.

For the record, then, it would look like this:

if option:
import optionon as optionmodule
else:
import optionoff as optionmodule

x = optionmodule.Foo( )

(assuming we can live with an Initialcaps class name).

It also now strikes me that a package might be appropriate here: Let
__init__.py sort things out and set up the package's namespace
accordingly; then the rest of the program would just use the package
obliviously. But:

- __init__.py has to have access to the option variable (solutions
abound; good solutions are less plentiful and vary over time and
space);

- given (a) my recent track record for getting the details correct
and (b) my lack of experience with the package system, I humbly
leave the rest of such a solution to the interested reader.

Regards,
Dan

--
Dan Sommers
<http://www.tombstonezero.net/dan/>
Never play leapfrog with a unicorn.
Jul 18 '05 #7
Dan Sommers <me@privacy.net> wrote in message news:<m2************@unique.fully.qualified.domain .name.yeah.right>...
On Tue, 03 Aug 2004 23:46:32 +0200,
Peter Otten <__*******@web.de> wrote:
Jeff Shannon wrote:
Or even better:

if option:
import WithOption as FooModule
else:
import WithoutOption as FooModule

x = FooModule.Foo( )

(I twitch every time I see 'from X import *' ...)


Yep, you're right. I always forget about the "as" option.
That, and mixed-case module names -- and no, I'm not advertising
all-uppercase here...


My mistake again. The names I chose were for illustrative and
explicative purposes only; nothing else was (meant to be) implied.

For the record, then, it would look like this:

if option:
import optionon as optionmodule
else:
import optionoff as optionmodule

x = optionmodule.Foo( )

(assuming we can live with an Initialcaps class name).

It also now strikes me that a package might be appropriate here: Let
__init__.py sort things out and set up the package's namespace
accordingly; then the rest of the program would just use the package
obliviously. But:

- __init__.py has to have access to the option variable (solutions
abound; good solutions are less plentiful and vary over time and
space);

- given (a) my recent track record for getting the details correct
and (b) my lack of experience with the package system, I humbly
leave the rest of such a solution to the interested reader.


How about the pygtk style "require":
import pygtk
pygtk.require('2.0')
import gtk # uses state set by the "require" call.

This always seems a clean interface to me. Much safer and cleaner than
something peeking at a global (or environment) variable.
Jul 18 '05 #8
On 9 Aug 2004 06:59:47 -0700,
gr*@ll.mit.edu (george young) wrote:
How about the pygtk style "require":
import pygtk
pygtk.require('2.0')
import gtk # uses state set by the "require" call. This always seems a clean interface to me. Much safer and cleaner
than something peeking at a global (or environment) variable.


Our mileage has varied. That one always seemed very unclean to me.

In my mind, pygtk sits on top of gtk, and that interface requires gtk to
look "up" to figure out what to do. Nothing inside gtk should depend on
(or even know about) anything inside pygtk.

Regards,
Dan

--
Dan Sommers
<http://www.tombstonezero.net/dan/>
Never play leapfrog with a unicorn.
Jul 18 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

10 posts views Thread by florian kno | last post: by
10 posts views Thread by Lord Labakudas | last post: by
3 posts views Thread by John C | last post: by
9 posts views Thread by Rune | last post: by
9 posts views Thread by =?ISO-8859-1?Q?Janne_H=E4rk=F6nen?= | last post: by
32 posts views Thread by Immortal Nephi | last post: by
reply views Thread by mihailmihai484 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.