At Monday 11/12/2006 19:11, Bernard Lebel wrote:

If by "shortening the PYTHONPATH" you meant having less paths, I
hardly see how I could do less than what I do with the pth. All these
paths seem to be built in.

I mean, delete the ones that actually don't exist. sys.path is a simple list; you can traverse it (perhaps backwards is easier) in site.py or sitecustomize.py and delete unexistant entries. Moving the network related paths (\\linuxserver\...) towards the end may help (if you don't get conflicts by finding the wrong module in the wrong place)

[Fredrik Lundh] a plain Python 2.4 interpreter can start, execute a
command, and shut
down in about 0.13 seconds on my machine.  2.5 does the same thing in
0.10 seconds.

[Bernard] The problem is not firing up the standalone Python
interpreter. The problem is firing the application that embeds a
Python interpreter.

As explained above, when I start this application, many files are
looked in many different places. All PYTHONPATH locations are
traversed, where pyd-dll-py-pyw-pyc files are searched. Many of these
files are searched in highly improbable locations.

But the whole process takes about 3sec - as seen on your log. (enabling ms resolution on FileMon may help too, because the timing is now too much rough)

[Fredrik Lundh] are you sure you're benchmarking *Python's* start up
time, and not the
time it takes to load all the modules used by your application, or the
time it takes for "filemon" to print all those 4500 requests to the
monitor window?

[Bernard] The Filemon overhead consistently clocks at 1 second, not
matter the test I perform. Since I ran all tests with Filemon running,
I feel safe to ignore this constant.

Now, as to the first sentence, to be fair, no, I'm not exactly sure. I
don't know all the details of the Python's embedding in this software,
and this knowledge is out of my reach atm.

Have you tried running the interpreter alone? Not your embedded application.
Try invoking python with the -v flag. For an embedded application, define PYTHONVERBOSE=1 in the environment before running. Perhaps it's not Python which slows down your startup, but other parts of the app.


--
Gabriel Genellina
Softlab SRL
__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis! ¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar
-- 
http://mail.python.org/mailman/listinfo/python-list

Reply via email to