Comments on: Python vs. Java: An update to a subjective speed comparison http://www.snaplogic.com/blog/?p=55 Thoughts on Open Source, Data Services, and Integration Tue, 25 May 2010 18:04:25 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: C++ vs Java vs Python « Computing Life http://www.snaplogic.com/blog/?p=55&cpage=1#comment-68089 C++ vs Java vs Python « Computing Life Thu, 29 Apr 2010 12:34:39 +0000 http://blog.snaplogic.org/?p=55#comment-68089 [...] have not compared the performance of Java vs Python. But i assumed Python could be slower from what i have heard on the web. Please do correct me if iam wrong on the above [...] [...] have not compared the performance of Java vs Python. But i assumed Python could be slower from what i have heard on the web. Please do correct me if iam wrong on the above [...]

]]> By: Java != Slow « Thermal Noise http://www.snaplogic.com/blog/?p=55&cpage=1#comment-1372 Java != Slow « Thermal Noise Fri, 07 Sep 2007 20:49:21 +0000 http://blog.snaplogic.org/?p=55#comment-1372 [...] back to the original topic of Java != Slow, here is an interesting study comparing Python and Java where Java is in some cases 30x faster than python even with Psyco [...] [...] back to the original topic of Java != Slow, here is an interesting study comparing Python and Java where Java is in some cases 30x faster than python even with Psyco [...]

]]> By: SnapLogic » Python - the first and last language you’ll ever need http://www.snaplogic.com/blog/?p=55&cpage=1#comment-358 SnapLogic » Python - the first and last language you’ll ever need Tue, 07 Aug 2007 18:48:41 +0000 http://blog.snaplogic.org/?p=55#comment-358 [...] this post here when during the heated discussion that took place on reddit.com about my recent Python vs. Java speed comparison post I learned about a new way to describe Python: Executable pseudo [...] [...] this post here when during the heated discussion that took place on reddit.com about my recent Python vs. Java speed comparison post I learned about a new way to describe Python: Executable pseudo [...]

]]> By: Graphic Rezidew http://www.snaplogic.com/blog/?p=55&cpage=1#comment-230 Graphic Rezidew Sun, 29 Jul 2007 16:17:57 +0000 http://blog.snaplogic.org/?p=55#comment-230 Interesting, I'd like to see how those come out with Jython/JPython. I've often wondered whether the interpreter overhead in Jython would be worth some of the potential advantages of being able to program in a Java environment without having to USE java. Interesting, I’d like to see how those come out with Jython/JPython. I’ve often wondered whether the interpreter overhead in Jython would be worth some of the potential advantages of being able to program in a Java environment without having to USE java.

]]> By: James Cornell http://www.snaplogic.com/blog/?p=55&cpage=1#comment-218 James Cornell Sat, 28 Jul 2007 10:52:40 +0000 http://blog.snaplogic.org/?p=55#comment-218 It's also worth noting the flexibility of Java for use with UI's and web-based applications out of the box. With 3500 classes, Java has two main UI toolkits, Swing and AWT. It supports many things that Python can't do out of the box, and that Python doesn't even have as a module. It's worth noting that Python scripts over 10,000 lines initialize quite slow just like Java, and that bytecode optimizations, although supported with Python, are not the norm and are not common. Coding for wxwidgets, using a QT or GTK bridge, or using TCL/TK is hardly an optimal solution when writing complex graphical applications, and Java wins in this area, despite there comically being many problems with the look and feel of Java applications. This has changed since 5.0, with drag-and-drop and other common native GUI aspects being available with Java now. Writing web-only applications is better with Python, mainly because of it being on more hosting providers, although Ruby is far more common than either Java or Python on shared hosts. Write once, run everywhere still mainly holds true for Java, minus some GUI kludge, but at least the consistancy of the kludge is the same across the platforms. I prefer Java to Python because it's also better documented, has more books to learn from, and is also GPL just like Python, so more people can have it out of the box if they chose to be liberal and not support anything not-FOSS. As for writing web applications, Python wins, but it's worth noting a good programmer will just use XML and SOAP, and integrate it using JSP or PHP on the server-side, using the same stuff on the client. Unfortunately the install base again for Java is even smaller than Python on servers, so resorting to ugly PHP XMLRPC stuff is a necessity if you can't afford your own dedicated server. It’s also worth noting the flexibility of Java for use with UI’s and web-based applications out of the box. With 3500 classes, Java has two main UI toolkits, Swing and AWT. It supports many things that Python can’t do out of the box, and that Python doesn’t even have as a module. It’s worth noting that Python scripts over 10,000 lines initialize quite slow just like Java, and that bytecode optimizations, although supported with Python, are not the norm and are not common.

Coding for wxwidgets, using a QT or GTK bridge, or using TCL/TK is hardly an optimal solution when writing complex graphical applications, and Java wins in this area, despite there comically being many problems with the look and feel of Java applications. This has changed since 5.0, with drag-and-drop and other common native GUI aspects being available with Java now.

Writing web-only applications is better with Python, mainly because of it being on more hosting providers, although Ruby is far more common than either Java or Python on shared hosts. Write once, run everywhere still mainly holds true for Java, minus some GUI kludge, but at least the consistancy of the kludge is the same across the platforms. I prefer Java to Python because it’s also better documented, has more books to learn from, and is also GPL just like Python, so more people can have it out of the box if they chose to be liberal and not support anything not-FOSS.

As for writing web applications, Python wins, but it’s worth noting a good programmer will just use XML and SOAP, and integrate it using JSP or PHP on the server-side, using the same stuff on the client. Unfortunately the install base again for Java is even smaller than Python on servers, so resorting to ugly PHP XMLRPC stuff is a necessity if you can’t afford your own dedicated server.

]]> By: Isaac Gouy http://www.snaplogic.com/blog/?p=55&cpage=1#comment-128 Isaac Gouy Fri, 13 Jul 2007 00:14:54 +0000 http://blog.snaplogic.org/?p=55#comment-128 Psyco 1.4X slower than Java Psyco 20X slower than Java Psyco 30X slower than Java why haven't you written these Java faster than ... Java faster than ... Java faster than ... Psyco 1.4X slower than Java
Psyco 20X slower than Java
Psyco 30X slower than Java

why haven’t you written these

Java faster than …
Java faster than …
Java faster than …

]]> By: Juergen http://www.snaplogic.com/blog/?p=55&cpage=1#comment-120 Juergen Thu, 12 Jul 2007 18:30:26 +0000 http://blog.snaplogic.org/?p=55#comment-120 Good point! The IO performance of Java certainly diminishes if I use the non-buffered option you have pointed out. When I compare that to the non-buffered (!) Java version (the initial test), then Java is around 10x faster. This now surprises me a little bit. On my machine, Java takes its 0.49 seconds, and Python now takes around 5 seconds. Replacing the call to write() with a dummy function call, I can see that only 0.85 of those 5 seconds are spend in loop, object creation and function call overhead. Good point! The IO performance of Java certainly diminishes if I use the non-buffered option you have pointed out. When I compare that to the non-buffered (!) Java version (the initial test), then Java is around 10x faster. This now surprises me a little bit.

On my machine, Java takes its 0.49 seconds, and Python now takes around 5 seconds. Replacing the call to write() with a dummy function call, I can see that only 0.85 of those 5 seconds are spend in loop, object creation and function call overhead.

]]> By: Isaac Gouy http://www.snaplogic.com/blog/?p=55&cpage=1#comment-110 Isaac Gouy Thu, 12 Jul 2007 04:32:05 +0000 http://blog.snaplogic.org/?p=55#comment-110 1) "Update - if I think about buffered IO under Java for performance improvement then I should also consider that for the Python cases, which I am not doing here" On the contrary I expect /you are/ using buffered io for Python - check by opening 'scratch' with 0 buffer: f=open('scratch','wb',0) for i in xrange(1000000): f.write(str(i)) f.close() and time the program. How much slower is it? 1) “Update – if I think about buffered IO under Java for performance improvement then I should also consider that for the Python cases, which I am not doing here”

On the contrary I expect /you are/ using buffered io for Python – check by opening ’scratch’ with 0 buffer:

f=open(’scratch’,'wb’,0)
for i in xrange(1000000):
f.write(str(i))
f.close()

and time the program. How much slower is it?

]]> By: Isaac Gouy http://www.snaplogic.com/blog/?p=55&cpage=1#comment-97 Isaac Gouy Wed, 11 Jul 2007 00:13:50 +0000 http://blog.snaplogic.org/?p=55#comment-97 "Large differences, however, are likely to be valid." Kind of depends on whether the self reported times exaggerated by a little or a lot :-) Remember to follow the reports conclusion and take the results with a grain of salt. “Large differences, however, are likely to be valid.”

Kind of depends on whether the self reported times exaggerated by a little or a lot :-)

Remember to follow the reports conclusion and take the results with a grain of salt.

]]> By: Juergen http://www.snaplogic.com/blog/?p=55&cpage=1#comment-96 Juergen Tue, 10 Jul 2007 23:52:00 +0000 http://blog.snaplogic.org/?p=55#comment-96 Isaac: I read that validity section. In that very same section, however, the authors of the paper give the reasons why by and large they do consider the work-time estimates even for the 'script group' as relevant. There were a few other differences in the test setup for the two groups, but in the summary (also in the validity section) the authors reaffirm that while small differences may be accounted for this way, the overall conclusion should still be seen as valid. Isaac: I read that validity section. In that very same section, however, the authors of the paper give the reasons why by and large they do consider the work-time estimates even for the ’script group’ as relevant.

There were a few other differences in the test setup for the two groups, but in the summary (also in the validity section) the authors reaffirm that while small differences may be accounted for this way, the overall conclusion should still be seen as valid.

]]>