I learned a lot from the other thread 'Is a "real" C-Python possible?' about Python performance and optimization. I'm almost convinced that Python's performance is pretty good for this dynamic language although there are areas to improve, until I read some articles that say IronPython is a few times faster. I find it amazing that something that's written in C and runs on hardware is slower than a .NET app that runs on CLR as managed code: http://www.python.org/~jeremy/weblog/031209a.html http://blogs.msdn.com/jasonmatusow/archive/2005/03/28/402940.aspx

In article <AKadnfFri82G2vXanZ2dnUVZ_s6mnZ2d@comcast.com>, "Jack" <nospam@invalid.com> wrote: > I learned a lot from the other thread 'Is a "real" C-Python possible?' about > Python performance and optimization. I'm almost convinced that Python's > performance is pretty good for this dynamic language although there are > areas to improve, until I read some articles that say IronPython is a few > times faster. I find it amazing that something that's written in C and runs > on hardware is slower than a .NET app that runs on CLR as managed code: > > http://www.python.org/~jeremy/weblog/031209a.html > http://blogs.msdn.com/jasonmatusow/archive/2005/03/28/402940.aspx You might argue that Python programs executed using CPython "run on hardware" to a *lesser* extent than they do when run in IronPython. In either case, your program is parsed and compiled into bytecode (Python bytecode or MSIL), then loaded by the Python virtual machine or the .NET VM, respectively. But whereas the Python VM is a bytecode interpreter, the .NET VM, like Java, uses just-in-time compilation to translate MSIL bytecode to optimized machine code for more efficient execution. This is probably the most important factor in the performance difference demonstrated in the above links. The fact that the IronPython compiler is written in C# and therefore runs from the VM, whereas the CPython compiler is compiled straight to machine code, is unimportant. Even if a significant performance difference did result from this, keep in mind that the bulk of the execution time of any Python app worth profiling is going to be after this initial Python-to-bytecode compilation, during the execution of the program's bytecode itself. -- Mark Shroyer http://markshroyer.com/contact/

Jack <nospam@invalid.com> wrote: >I learned a lot from the other thread 'Is a "real" C-Python possible?' about >Python performance and optimization. I'm almost convinced that Python's >performance is pretty good for this dynamic language although there are >areas to improve, until I read some articles that say IronPython is a few >times faster. In my limitted experience, IronPython is slower than CPython. I can't actually get much to run with IronPython, but what I have been able to get working runs slower. In particular initialization time takes much longer. A command line utility of mine that takes 1.5 seconds to run with CPython, ends up taking 20 seconds with IronPython. That 3 seconds for IronPython's own startup and initilization, 12 seconds for importing modules, and 5 seconds for the rest. Ross Ridge -- l/ // Ross Ridge -- The Great HTMU [oo][oo] rridge@csclub.uwaterloo.ca -()-/()/ http://www.csclub.uwaterloo.ca/~rridge/ db //