On Fri, 24 Jun 2011 04:00:17 +1000, Chris Angelico wrote: > On Fri, Jun 24, 2011 at 2:58 AM, Eric Snow <ericsnowcurren...@gmail.com> > wrote: >> So, which are the other pieces of Python that really need the heavy >> optimization and which are those that don't? Thanks. >> >> > Things that are executed once (imports, class/func definitions) and
You can't assume that either of those things are executed once. Consider this toy example: def outer(a, b): def inner(x): return (x*a - b)*(x*b - a) - 1 return inner(b**2 - a**2) results = [outer(a, b) for (a, b) in coordinate_pairs()] The function definition for inner gets executed repeatedly, inside a tight loop. Fortunately Python does optimize this case. The heavy lifting (parsing the source of inner, compiling a code object) is done once, when outer is defined, and the only work done at runtime is assembling the pieces into a function object, which is fast. Similarly, imports are so expensive that it makes sense to optimize them. A single line like "import module" requires the following work: - expensive searches of the file system, looking for a module.py file or a module/__init__.py package, possibly over a slow network or inside zip files; - once found, parse the file; - compile it; - execute it, which could be arbitrarily expensive; - and which may require any number of new imports. Again, imports are already optimized in Python: firstly, once a module has been imported the first time, the module object is cached in sys.modules so that subsequent imports of that same module are much faster: it becomes little more than a name lookup in a dict. Only if that fails does Python fall back on the expensive import from disk. Secondly, Python tries to cache the compiled code in a .pyc or .pyo file, so that parsing and compiling can be skipped next time you import from disk (unless the source code changes, naturally). And even so, importing is still slow. That's the primary reason why Python is not suitable for applications where you need to execute lots of tiny scripts really fast: each invocation of the interpreter requires a whole lot of imports, which are slow the first time. (Still, Python's overhead at startup time is nowhere near as expensive as that of Java... but Java is faster once started up.) -- Steven -- http://mail.python.org/mailman/listinfo/python-list