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