> Of course, you still have the actual interpretation of > the top-level module code - if it's not the marshalling > but this part that actually costs performance, this > efficient marshalling algorithm won't help. It would be > interesting to find out which modules have a particularly > high startup cost - perhaps they can be rewritten > > > I am afraid this is the case.
Is that an unfounded or a founded fear? IOW, do you have hard numbers proving that it is the actual interpretation time (rather than the marshaling time) that causes the majority of the startup cost? > I hope we could marshal an arbitary > application state (not even Python specific) into a fast loading dump > file (hibernation/snapshot). I understand that this is what you want to get. I'm proposing that there might be a different approach to achieve a similar speedup. > logging - defines lots of classes which are used only if they are > specified by logging options. I once hacked this for my personal use to > be little lighter. So what speedup did you gain by rewriting it? (i.e. how many microseconds did "import logging" take before, how much afterwards?) How much of it was parsing/unmarshaling, and how much time byte code interpretation? Of the byte code interpretation, what opcodes in particular? > urllib - particular heavy, imports httplib, ftplib and stuff even if it > is not used Same questions here. This doesn't sound like any heavy computation is being done during startup. > Nokia has just released Python 2.5 based PyS60. I think we'll come back > this after a while with a nice generic profiler which will tell the > import cost. Looking forward to hear your numbers! Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
