Pyhton Interpreter Startup time

[Neil Benn]

Hello,

I'm looking at a small app which would need a very quick
startup time for the Python interpreter. It doesn't do much (copying
and caching of files, no GUI) but I need the Python interpreter to start
up very quickly (<1 second on a Windows box). Is there a way to have a
'stripped' down Python interpreter which can start up very quickly on a
windows box. Once thing I was thinking of was to use PyExe to make a
quick startup (does it compile down to C code, therefore not using the
Python interpreter at runtime?). Is this a possible solution?

I observe that the second time I start python it starts up quicker
but I'm assuming that this is dependent on the environment and can't be
relied upon (or something like that).

Thanks, in advance for your help.

Cheers,

Neil

--

Neil Benn
Senior Automation Engineer
Cenix BioScience
BioInnovations Zentrum
Tatzberg 47
D-01307
Dresden
Germany

Tel : [phone]
e-mail : be**@cenix-bioscience.com
Cenix Website : http://www.cenix-bioscience.com

[Peter Hansen]

Neil Benn wrote:

I'm looking at a small app which would need a very quick
startup time for the Python interpreter. It doesn't do much (copying
and caching of files, no GUI) but I need the Python interpreter to start
up very quickly (<1 second on a Windows box).

What kind of machine do you have?

On mine, Python starts up in about 0.06 seconds...

This primitive test shows these results on a Windows XP machine
(it won't work with Windows 98 as it can't chain commands on the
command line like that, but you could but it in a batch file).

c:\>echo. | time & python -c "import time; print time.time()"
The current time is: 8:59:59.67
Enter the new time:
1092315599.73

This is a fairly fast machine (Athlon 2500+) but I really
doubt slower machines would take much longer than 1 second
unless they are *really* old.

-Peter

[Cousin Stanley]

Peter Hansen wrote ....

Neil Benn wrote:

I'm looking at a small app which would need a very quick
startup time for the Python interpreter. It doesn't do much (copying
and caching of files, no GUI) but I need the Python interpreter to start
up very quickly (<1 second on a Windows box).

What kind of machine do you have?

On mine, Python starts up in about 0.06 seconds...

This primitive test shows these results on a Windows XP machine
(it won't work with Windows 98 as it can't chain commands on the
command line like that, but you could but it in a batch file).

c:\>echo. | time & python -c "import time; print time.time()"
The current time is: 8:59:59.67
Enter the new time:
1092315599.73

This is a fairly fast machine (Athlon 2500+) but I really
doubt slower machines would take much longer than 1 second
unless they are *really* old.

-Peter

This variation on Peter's timing
is from a 5-year-old 250 MHz Compaq
running Linux/Debian ...

sk@cpq1 : ~/c $ ./gtod & python -c "import time ;
print ' Python ....' , time.time()"
[1] 1677

Number of seconds ......... 1092323003
Number of microseconds .... 194433
Time zone ............... .. 420
Daylight savings time ..... 0

Python .... 1092323003.36
--
Cousin Stanley
Human Being
Phoenix, Arizona

[Christopher T King]

On Thu, 12 Aug 2004, Neil Benn wrote:

Is there a way to have a 'stripped' down Python interpreter which can
start up very quickly on a windows box.
Two things you can do are:

1) Run Python as "python -S". Normally, Python does an 'import site'
before running other code. Starting with 2.3, this does lots of expensive
localization goo, etc.; my guess is your script doesn't need it to execute
correctly, if it doesn't use any i18n functions.

2) Pre-compile the script. Normally, Python generates .pyc files for
imported modules so it doesn't have to re-parse the source code, but it
won't do this for a script specified on the command line. You can force
it to compile your script by importing the script in the interactive
interpreter, but this will also run your script (possibly not desirable).
You can compile the script without running it by using the py_compile
module:

python -c 'import py_compile; py_compile.comp ile("my_script. py")'

You can then run the compiled version using 'python my_script.pyc'
('python my_script.py' will ignore the compiled version).
Once thing I was thinking of was to use PyExe to make a
quick startup (does it compile down to C code, therefore not using the
Python interpreter at runtime?). Is this a possible solution?

Nope. py2exe just embeds the Python interpreter in the .exe. If
anything, startup would be slower, since py2exe also places all required
modules in a ZIP archive.

[simo]

Neil Benn <be**@cenix-bioscience.com> wrote in message news:<ma******* *************** *************** *@python.org>.. .

Hello,

I'm looking at a small app which would need a very quick
startup time for the Python interpreter. It doesn't do much (copying
and caching of files, no GUI) but I need the Python interpreter to start
up very quickly (<1 second on a Windows box). Is there a way to have a
'stripped' down Python interpreter which can start up very quickly on a
windows box.
This has been discussed before, there's definitely something "odd"
about the Windows startup time in comparison to the UNIX "instant"
startup.
Once thing I was thinking of was to use PyExe to make a
quick startup (does it compile down to C code, therefore not using the
Python interpreter at runtime?). Is this a possible solution?
Nope, no compiling to C/machine code, just bytecode, and the
interpreter is a DLL.
I observe that the second time I start python it starts up quicker
but I'm assuming that this is dependent on the environment and can't be
relied upon (or something like that).

Yeah, I think that's something to do with Windows caching.

I keep saying, we need a Python compiler.....

[Peter Hansen]

simo wrote:

Neil Benn <be**@cenix-bioscience.com> wrote in message news:<ma******* *************** *************** *@python.org>.. .

I'm looking at a small app which would need a very quick
startup time for the Python interpreter. It doesn't do much (copying
and caching of files, no GUI) but I need the Python interpreter to start
up very quickly (<1 second on a Windows box). Is there a way to have a
'stripped' down Python interpreter which can start up very quickly on a
windows box.

This has been discussed before, there's definitely something "odd"
about the Windows startup time in comparison to the UNIX "instant"
startup.

Discussed, but not to a satisfactory conclusion I think.

The fact that some of us have near instantaneous startup times,
consistently (whether immediately after reboot or not) on Windows,
even with older machines, suggests strongly that those who do
not have something *wrong* with their system.

I don't recall the OP in the last thread that discussed this
ever coming back to report on exactly what OS and CPU etc.
he was using, and whether network issues might be involved,
etc, so until someone can prove otherwise, I think it's
safe to assume that anyone with a slow startup on Windows
has a misconfiguratio n or is doing something wrong.

-Peter

[Aahz]

In article <Pi************ *************** **********@ccc8 .wpi.edu>,
Christopher T King <sq******@WPI.E DU> wrote:

2) Pre-compile the script. Normally, Python generates .pyc files for
imported modules so it doesn't have to re-parse the source code, but it
won't do this for a script specified on the command line. You can force
it to compile your script by importing the script in the interactive
interpreter, but this will also run your script (possibly not desirable).
You can compile the script without running it by using the py_compile
module:

python -c 'import py_compile; py_compile.comp ile("my_script. py")'

You can then run the compiled version using 'python my_script.pyc'
('python my_script.py' will ignore the compiled version).

That's a Bad Idea. Better Idea: move the code into a separate module
and put the code into a function. Then change this script into a very
short driver that imports/calls the function.
--
Aahz (aa**@pythoncra ft.com) <*> http://www.pythoncraft.com/

"To me vi is Zen. To use vi is to practice zen. Every command is a
koan. Profound to the user, unintelligible to the uninitiated. You
discover truth everytime you use it." --*****@lion.aust in.ibm.com

[3c273]

"Aahz" <aa**@pythoncra ft.com> wrote in message
news:cf******** **@panix1.panix .com...

In article <Pi************ *************** **********@ccc8 .wpi.edu>,
Christopher T King <sq******@WPI.E DU> wrote:

*snip*

You can then run the compiled version using 'python my_script.pyc'
('python my_script.py' will ignore the compiled version).

That's a Bad Idea.

*snip*

Hello,
I'm pretty new to Python and programming in general but I have done this
before. Why is this a bad idea?
Also (maybe not the right place to ask, but...), I was thinking of driving
up to BayPiggies because I am interested in tonights discussion but it's a
long drive and I'm afraid it would be way over my head. Do you get a lot of
newbie participants? Thanks for your input.
Louis

[Cousin Stanley]

| ....
| This primitive test shows these results on a Windows XP machine
| ( it won't work with Windows 98
| as it can't chain commands
| on the command line like that,
| but you could but it in a batch file ).
| ....

I stuck it in a .bat file under Win98_SE
on the same dual-boot machine that I used
for the Linux/Debian test ....

Win98_SE .... Python 2.3 Enthought Edition
Debian ...... Python 2.3.4

< K:\C\MinGWStudi o\Samples\Time\ Debug >
Thu 08-12-2004 18:49:03.23
py_time

Number of Seconds Since January 1, 1970 ....

1092361745
1092361746.75

The Linux/Debian number is only slightly quicker
with Python 2.3.4 and probably given a larger number
of tests, there might be no significant difference ....

Number of seconds ......... 1092323003
Python ............... ..... 1092323003.36

So, for an old 250 MHz machine, I seem to be loading
Python OK for both Win98 & Linux ....
--
Cousin Stanley
Human Being
Phoenix, Arizona

[Neil Benn]

Peter Hansen wrote:

<snip>
I don't recall the OP in the last thread that discussed this
ever coming back to report on exactly what OS and CPU etc.
he was using, and whether network issues might be involved,
etc, so until someone can prove otherwise, I think it's
safe to assume that anyone with a slow startup on Windows
has a misconfiguratio n or is doing something wrong.

<snip>
Hello,

Hi, I'm the OP, my box is :

WinXP Pro
2.4Gz Processor
256M RAM
Python2.3

As I said the first load takes 5 seconds and the consecutive loads
take fractions of a second - my assumption is that Windows is caching
something which is not suitable for my needs as it is not predictable
enough. There is no network issues involved in this, everything is
running off the local hard drive. I've just this moment run python
after the box having done some work and being asleep overnight and the
startup time was about 2 seconds. I may be doing something wrong but
the only configuration stuff I've done is to add into my environment
variables :

PYTHON_HOME=c:\ program files\python23
PATH=%PATH%;PYT HON_HOME

This is simply to allow me to switch between different python
directories when I start to install different versions (I do the same
with the JVM). If python can't start up quick on windows, that's fine,
if I've got something miscofigured which can be fixed, that's fine too -
I just need to know if there is a 'quick start up' mode but if there
isn't then that's also fine. It's just info I need to design what will
be a very simple app.

Thanks, for your help.

Cheers,

Neil

--

Neil Benn
Senior Automation Engineer
Cenix BioScience
BioInnovations Zentrum
Tatzberg 47
D-01307
Dresden
Germany

Tel : [phone]
e-mail : be**@cenix-bioscience.com
Cenix Website : http://www.cenix-bioscience.com