Python比Java/ c#慢吗?

Is Python slower than Java/C#?

Python比Java/ c#慢吗?

performance-comparison-c-java-python-ruby-jython-jruby-groovy

performance-comparison-c-java-python-ruby-jython-jruby-groovy

Here is a project that optimizes CPython: unladen-swallow

这里有一个优化CPython: unladen-swallow的项目。

13 个解决方案

#1

Don't conflate Language and Run-Time.

不要混淆语言和运行时。

Python (the language) has many run-time implementations.

Python(语言)有许多运行时实现。

• CPython is usually interpreted, and will be slower than native-code C#. It might be slower than Java, depending on the Java JIT compiler.

  CPython通常被解释，并且会比原生代码c#慢。它可能比Java慢，这取决于Java JIT编译器。

• JYthon is interpreted in the JVM and has the same performance profile as Java.

  JYthon在JVM中解释，并且具有与Java相同的性能概要。

• IronPython relies on the same .NET libraries and IL as C#, so the performance difference will be relatively small.

  IronPython依赖于与c#相同的. net库和IL，因此性能差异相对较小。

• Python can be translated to native code via PyREX, PyToC, and others. In this case, it will generally perform as well as C++. You can -- to an extent -- further optimize C++ and perhaps squeeze out a little bit better performance than unoptimized output from PyREX.

  Python可以通过PyREX、PyToC和其他方式转换到本机代码。在这种情况下，它的性能通常与c++一样好。在某种程度上，您可以进一步优化c++，也许还可以挤出比PyREX未优化的输出更好的性能。

  For more information, see http://arcriley.blogspot.com/2009/03/so-long-pyrex.html

  有关更多信息，请参见http://arcriley.blogspot.com/2009/03/so-long-pyrex.html

Note that Python (the language) is not slow. Some Python run-times (CPython, for example) will be slower than native-code C++.

请注意，Python(语言)并不慢。一些Python运行时(例如CPython)将比原生代码c++慢。

#2

It is not really correct to ask why Python is slower than Java/C#. How fast is Java? Well, naive interpreters are around ten times slower than optimised compilers. I believe there is a Java bytcode interpreter written in JavaScript - that probably isn't very fast. So, the intended question appears to be "Why is the CPython language system slower than the equivalent Sun, IBM and Oracle JRE and Microsoft .NET runtime?"

问为什么Python比Java/ c#慢是不正确的。Java有多快?天真的解释器比优化过的编译器慢十倍。我相信有一个用JavaScript编写的Java字节码解释器——这可能不是很快。因此，预期的问题似乎是“为什么CPython语言系统比等效的Sun、IBM、Oracle JRE和Microsoft .NET运行时慢?”

I believe the correct answer is non-technical. The fastest Java and .NET runtime are faster because they have large full time technical teams developing them in performance-competitive environment.

我认为正确的答案是非技术性的。最快的Java和。net运行时更快，因为它们有大量的全职技术团队在性能竞争环境中开发它们。

Dynamic language systems are easy to implement. Any idiot can do it. I have. Static language systems are more complex to design and implement. A simple static system will tend to run much faster than the equivalent just-working dynamic equivalent. However, it is possible for highly optimised dynamic systems to run almost as fast. I understand some Smalltalk implementation were quite good. An often quoted example of a developed dynamic system is the MIT Lisp Machine.

动态语言系统很容易实现。任何白痴都能做到。我有。静态语言系统的设计和实现更加复杂。一个简单的静态系统比等效的动态系统运行得快得多。然而，对于高度优化的动态系统来说，几乎可以同样快地运行。我知道一些Smalltalk实现相当不错。一个经常被引用的开发动态系统的例子是MIT Lisp机器。

In addition if the real grunt is being done by library code, then the language system may not matter. Alternatively, the language may encourage (or give time(!)) to develop more efficient algorithms which can easily wipe out constant factor performance differences.

此外，如果真正的咕哝是由库代码完成的，那么语言系统可能并不重要。或者，该语言可能鼓励(或给时间(!)开发更有效的算法，可以轻松消除常数因子性能差异。

#3

As mentioned in the other answers this depends on the run-time system as well as the task at hand. So the standard (C)Python is not necessarily slower than Java or C#. Some of its modules are implemented in C. Thus combining speed of a native implementation with Python's language.

正如在其他答案中提到的，这取决于运行时系统和手头的任务。因此，标准(C)Python并不一定比Java或c#慢。它的一些模块是用c实现的，因此结合了本地实现的速度和Python的语言。

We did a small experiment: We compared the execution time of a Factorial computation in different languages. The test was actually intended to evaluate the performance of arbitrary-precision integers implementations.

我们做了一个小实验:我们用不同的语言比较阶乘计算的执行时间。这个测试实际上是为了评估任意精度整数实现的性能。

testee. language arbitrary-precision integers run-time

     1. Java     java.math.BigInteger         JRE 6.13
     2. .NET     System.Numerics.BigInteger   MS CLR 4.0
     3. Python   long                         Active Python 2.6.2.2
     4. Squeak   BigInt                       Squeak 3.10.2
     5. .NET     Mono.Math.BigInteger         MS CLR 4.0

results:

                 1)         2)       3)       4)        5)
   10.000!      343 ms    137 ms    91 ms  1.200 ms    169 ms
   20.000!    1.480 ms    569 ms   372 ms  1.457 ms    701 ms
   30.000!    3.424 ms  1.243 ms   836 ms  3.360 ms  1.675 ms
   40.000!    6.340 ms  2.101 ms 1.975 ms  6.738 ms  3.042 ms
   50.000!   10.493 ms  3.763 ms 3.658 ms 10.019 ms  5.242 ms
   60.000!   15.586 ms  7.683 ms 5.788 ms 14.241 ms 10.000 ms

alt text http://www.mycsharp.de/wbb2/attachment.php?attachmentid=6909&sid=0d5aa62b522d005d9e7089785b5d19f1

alt文本http://www.mycsharp.de/wbb2/attachment.php?attachmentid=6909&sid=0d5aa62b522d005d9e7089785b5d19f1

The bar chart shows the results. Python is the clear winner. As far as I know Python uses the Karatsuba-algorithm to multiply large integers, which explains the speed.

条形图显示了结果。Python显然是赢家。据我所知，Python使用karatsuba算法来相乘大整数，这解释了速度。

Besides, Python's "arbitrary-precision integers"-type is the built-in long. Hence you don't even need special type handling which is required for Java's BigInteger-class.

此外，Python的“任意精度整数”类型是内置的long。因此，您甚至不需要Java的bigint类所需要的特殊类型处理。

#4

Simply - Python is slow.

简单地说，Python是慢的。

No matter what interpreter (currently available) you use, it is slower than Java and C. In various benchmarks, its slower than Ruby and PHP. Do not depend on other's answers, check and verify yourself.

无论您使用什么解释器(当前可用)，它都比Java和c慢，在各种基准测试中都比Ruby和PHP慢。不要依赖别人的答案，自己验证一下。

http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=python3&lang2=java&data=u64q

http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=python3&lang2=java&data=u64q

Personally I do not think, there is much serious contribution and development done on getting python faster. Since the productivity is good in python and it solves some of problem straight forward, speed/performance is not taken seriously. There are some architecture issues too preventing Python getting performance tweaks.

就我个人而言，我不认为在使python更快方面有很多重要的贡献和开发。由于python的生产力很好，并且它可以直接解决一些问题，所以速度/性能没有受到重视。还有一些架构问题也会阻止Python获得性能调整。

Disclaimer - This answer probably will hurt Python lovers. I too am Python developer, loves developing webapps in Django/Flask/Pyramid rather than Spring (Java). But I see practically in my work and experience, how Python is slower. The speed is not always my priority. But I do stand with them, who says Python Interpreter should get oiling and greasing or total engine change to at least stand in marathon. It's a mainstream programming language.

免责声明:这个答案可能会伤害Python爱好者。我也是Python开发人员，喜欢用Django/Flask/Pyramid开发webapps，而不是用Spring (Java)。但在我的工作和经验中，我实际看到了Python是如何变慢的。我并不总是把速度放在第一位。但是我和他们站在一起，他们说Python解释器应该加油或者更换引擎，至少应该站在马拉松比赛中。它是一种主流的编程语言。

#5

As suggested in comments, you should really provide a test case to reason about. Reasons behind performance differences will change depending on the test being executed.

正如评论中所建议的，您应该提供一个测试用例来进行推理。性能差异背后的原因将根据所执行的测试而改变。

However, I'd suggest that the static vs dynamic nature may well have a lot to do with it. For non-virtual calls, the JIT-compiled C#/Java is extremely cheap as it can be determined accurately at JIT-time. Even virtual calls just involve a single level of redirection. When binding becomes dynamic, there's a wider range of things to consider.

然而，我认为静态和动态特性可能与此有很大关系。对于非虚拟调用，jit编译的c# /Java非常便宜，因为它可以在抖动时准确地确定。即使是虚拟调用也只涉及单一级别的重定向。当绑定变得动态时，需要考虑的事情就更广泛了。

I don't know enough details about Python to claim to understand its exact runtime behaviour, which I suspect may vary with version and implementation too. There is such a thing as "python byte code" which is then executed by a virtual machine - whether this virtual machine actually performs JIT-compilation or not is another matter.

我不知道关于Python的足够细节来声称理解其确切的运行时行为，我怀疑这也可能随版本和实现而有所不同。有这样一种东西，即“python字节码”，然后由虚拟机执行——不管这个虚拟机是否执行jit编译，都是另一回事。

#6

It boils down to the fact that the compilation phase has lesser information to work with and hence the runtime needs to do more work in case of duck typed (dynamically typed) languages.

它归结为这样一个事实:编译阶段需要处理的信息较少，因此运行时需要在鸭子类型(动态类型)语言的情况下做更多的工作。

Thus if I am making the method invocation foo.bar(), in case of Java or C++ the invocation to bar can be optimized in the compilation process by discovering the type of "foo" and then directly invoking the method at the memory location where the compiler knows it will be found. Since a python or any other dynamically typed language compiler does not know what type the object foo belongs to, it has to do a type check at runtime and then look up the address of the bar method and then invoke it.

因此，如果我正在进行方法调用foo.bar()，对于Java或c++，对bar的调用可以在编译过程中优化，方法是发现“foo”的类型，然后在编译器知道会找到的内存位置直接调用方法。由于python或任何其他动态类型化语言编译器不知道foo对象属于什么类型，所以它必须在运行时进行类型检查，然后查找bar方法的地址，然后调用它。

There are other difficulties a python compiler writer struggles with as well, though the one above hopefully adequately gives an indication. So even with the best compiler writers, statically typed languages are likely to perform much better at runtime.

python编译器编写者还面临着其他困难，尽管上面的那个很有希望给出一个指示。因此，即使有最好的编译器编写者，静态类型的语言在运行时也可能表现得更好。

Where dynamically typed languages score are typically in the development time. Due to fewer lines of code to write and maintain, and no compile wait times for developers, the development often goes through much faster.

动态类型化语言的得分通常在开发阶段。由于编写和维护的代码行更少，而且开发人员没有编译等待时间，开发过程通常会更快地完成。

#7

What you got there is clear example of writing Java in Python:

您得到的是用Python编写Java的清晰示例:

 def __init__(self,size):  
     self.first = None  
     last = None  
     for i in range(size):  
         current = Person(i)  
         if self.first == None : self.first = current  
         if last != None :  
             last.next = current  
             current.prev = last  
         last = current  
     self.first.prev = last  
     last.next = self.first  

A bit more pythonic:

一个神谕的点:

 def __init__(self,size):  
     chain = [Person(i) for i in range(size)]
     self.first = chain[0]
     chain = zip(chain, chain[1:].append(chain[0]))
     for p,n in chain:
        p.next = n
        n.prev = p

#8

I think it's ultimately that Python doesn't go as far as it can with optimizations. Most of the optimization techniques that are common are for static languages. There are optimization techniques for dynamic languages, but the modern ones don't seem to make as much use of them as they could. Steve Yegge has an excellent blog post on the subject.

我认为归根结底，Python并没有在优化方面走得尽可能远。大多数常见的优化技术都适用于静态语言。有一些动态语言的优化技术，但是现代的似乎并没有充分利用它们。史蒂夫·耶格(Steve Yegge)在这一主题上发表了一篇出色的博客文章。

EDIT: I just wanted to point out that I'm not necessarily stating this to be critical of Python. I prefer simplicity over unnecessary speed any day.

编辑:我只是想指出，我并不是说这是对Python的批评。比起不必要的速度，我更喜欢简单。

#9

It doesn't have anything to do with the languages themselves, it's just the fact that java implementation and runtime system (JVM) are very high quality, and that lots of resources have been invested in stability, scalability and performance improvements over the years.

它与语言本身没有任何关系，它只是java实现和运行时系统(JVM)是非常高质量的事实，多年来大量的资源被投入到稳定性、可扩展性和性能改进上。

Contrast that to the fact that CPython implementation just recently implemented eg threaded dispatch in its interpreter which gave it performance boost of up to 20% for certain problems. It's not a good thing as it sounds, it is bad because that kind of basic optimization should be there from the day one.

相比之下，CPython实现最近在其解释器中实现了eg线程调度，这使它在某些问题上的性能提高了20%。这听起来不是件好事，但却是件坏事，因为这种基本的优化应该从第一天就开始。

#10

This type of question can't be answered just by qualitative reasoning, you need good benchmarks to back it up. Here's one set that compare Python 3 vs C# Mono and find Python to be 3 to 300 times slower. The Python vs. Java results are similar. (The usual cautions about interpreting benchmarks apply.)

这种类型的问题不能仅仅通过定性推理来回答，你需要好的基准来支持它。这里有一个集合比较Python 3和c# Mono，发现Python的速度要慢3到300倍。Python和Java的结果是相似的。(通常对解读基准的警告也适用。)

These benchmarks also report the source code size, and Python was significantly more concise than Java and C#.

这些基准也报告源代码大小，Python比Java和c#更简洁。

#11

I think opposite. I can do simple program in Python faster than in Java, and those Python scripts work really fast.

我认为相反。我可以在Python中以比在Java中更快的速度完成简单的程序，而且这些Python脚本工作得非常快。

Of course your question without examples is hard to answer. Maybe you have found slow library, bug etc. Give us more details please.

当然你的问题没有例子很难回答。也许你已经找到了慢库，bug等。请给我们更多的细节。

#12

I would argue that the ease and simplicity of writing Python code makes it possible to write more complex code; for example, code that takes advantage of multi-core processors. Since per-core performance has been mostly stagnant for the past 5-10 years, I don't think it's clear that Python programs (whether they're running on CPython or something else) are slower in the long run.

我认为编写Python代码的简便性和简便性使编写更复杂的代码成为可能;例如，利用多核处理器的代码。由于每个内核的性能在过去的5-10年里几乎一直停滞不前，我认为从长远来看，Python程序(无论它们是在CPython上运行还是在其他程序上运行)的速度并不明显。

#13

Since it's interpreted and not compiled.. it should be slower in execution time.

因为它是被解释的而不是被编译的。它在执行时应该更慢。

As a table mentioned in Code Complete (second edition) book, page 600,

如《代码完整(第二版)》一书中提到的表，第600页，

C# equals C++ in execution time (1:1). And Python is slower above hundred times than C++ in execution time (>100:1).

c#在执行时间上等于c++(1:1)。在执行时，Python比c++慢了100倍(>100:1)。

And Java is slower than C++ by one time and a half (1.5:1).

Java的速度比c++慢了一倍半(1.5:1)。

These statistics are on average. I don't know who made this study, but seems interesting.

这些统计数字是平均的。我不知道是谁做的这项研究，但看起来很有趣。