15

According to this:

http://www.codeplex.com/IronPython/Wiki/View.aspx?title=IP20VsCPy25Perf&referringTitle=IronPython%20Performance

IronPython (Python for .Net) is faster than regular Python (cPython) on the same machine. Why is this? I would think compiled C code would always be faster than the equivalent CLI bytecode.

Tristan Havelick
  • 67,400
  • 20
  • 54
  • 64

5 Answers5

41

Python code doesn't get compiled to C, Python itself is written in C and interprets Python bytecode. CIL gets compiled to machine code, which is why you see better performance when using IronPython.

Serafina Brocious
  • 30,433
  • 12
  • 89
  • 114
  • 1
    There is one catch, though. I agree on why IronPython is faster. IronPython is slower in terms of startup time. (Which is not important if you are using the code regularly.) – ozgur May 05 '16 at 05:51
9

You're right, C is a lot faster. That's why in those results CPython is twice as fast when it comes to dictionaries, which are almost pure C. On the other hand, Python code is not compiled, it's interpreted. Function calls in CPython are terribly slow. But on the other hand: 

TryRaiseExcept:  +4478.9%

Now, there's where IronPython get is horribly wrong.

And then, there is this PyPy project, with one of the objectives being Just-In-Time compiler. There is even subset of Python, called RPython (Reduced Python) which can be statically compiled. Which of course is a lot faster.

vartec
  • 131,205
  • 36
  • 218
  • 244
  • I've always wondered why RPython hasn't been promoted more. It's sufficiently dynamic to be useful, yet very speedy. If there was more documentation for it I'd surely use it. – Daishiman Mar 07 '09 at 00:31
  • 7
    The PyPy team don't really want to encourage people to use RPython. They see it as an implementation detail of PyPy - it changes all the time, has poor documentation and terrible error reporting. They are concentrating on making the PyPy JIT fast enough that you don't *need* to use RPython to get speed... – fuzzyman Oct 05 '09 at 14:27
  • RPython is not intended to be used (or even cared by developer). It is just a subset PyPy uses to compile. If my understanding is not wrong, a subset, a part of your code will be compiled and some will still be interpreted. – ozgur May 05 '16 at 05:55
5

I'm not sure exactly how you're drawing the conclusion that IronPython is faster than CPython. The link that you post seems to indicate that they're good at different things (like exceptions as has been pointed out).

Jason Baker
  • 192,085
  • 135
  • 376
  • 510
5

Wandering off your question "Why?", to "Oh, really?" The "good at different things" (Jason Baker) is right on. For example, cpython beats IronPython hands down start up time. 

c:\Python26\python.exe Hello.py
c:\IronPython\ipy.exe Hello.py

Cpython executes a basic hello world nearly instantly(<100ms), where IronPython has an startup overhead of 4 or 5 seconds. This annoys me, but not enough to keep me from using IronPython.

Precipitous
  • 5,253
  • 4
  • 28
  • 34
  • 7
    That's not an advantage of CPython over IronPython for themselves. The 4 or 5 sconds are the startup time of the CLR, not of IronPython. – Rafa Castaneda Mar 10 '10 at 20:26
  • 2
    It doesn't matter why it takes 4 or 5 seconds more to start up. It's faster once its running (partly do to the CLR) but slower to start (partly due to the CLR). Performance considerations have significance based on user impact. If the use case for a scripting language is many small scripts, this is a severe drawback. – Precipitous Mar 18 '10 at 04:09
  • 2
    Perhaps the IronPython startup time can be reduced by a one-time action to pre-generate machine code for the IronPython .dll? See Microsoft's Ngen.exe (Native Image Generator) http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.110).aspx – ToolmakerSteve Dec 18 '13 at 21:30
  • As was pointed out elsewhere, Mono has the concept of Ahead Of Time complilation (AOT), which is explained on [its doc pages](http://www.mono-project.com/AOT). This will reduce startup all the time and run time in some cases but it is limited to certain processors (the common ones). – dirkjot May 15 '14 at 20:33
4

Could it be explained by this notation on the page you linked to:

Due to site caching in the Dynamic Language Runtime, IronPython performs better with more PyStone passes than the default value

Abtin Forouzandeh
  • 5,635
  • 4
  • 25
  • 28
  • Without knowing what site caching is (a very complex concept only really explained in a video series on Channel9), this tells you nothing. In addition, IPy1 (which was pre-DLR) also had better performance than CPython. It all comes down to CIL compilation. – Serafina Brocious Feb 02 '09 at 20:27