A place to discuss Joel on Software. Now closed.
This community works best when people use their real names. Please register for a free account.
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
Fog Creek Copilot
The Old Forum
Albert D. Kallal
In terms of VMs the theory has been that CLR VMs can optimize code a tad easier than JVM. But let's just say they are on par, how off can that be? Okay, there was a recent release of an IronPython exclusive. Resolver One is a spreadsheet app done in IronPython and on a Pentium 4 1.8GHz it crawls. It's not even usable. So there, the story for IronPython. Good luck with Jython then.
I had high hopes for Resolver One! I can't believe how slow it is! Didn't they realize it would be bad for their image to put that out there?
Is Resolver One really written in IronPython? If so, I don't see why they didn't write in in C# and just use IronPython as a scripting/macro language...
I downloaded and tried Resolver One to see if it's as slow as you to say it is. It's actually quite reasonable if you have a cup of coffee while it loads and check Data > Suspend Recalculations while entering data in.
Friday, February 15, 2008
I'm one of the Resolver One developers. I'm aware that importing Excel documents can be very slow (and will be much faster in version 1.1 - we have some cool optimizations) - but in general use it's pretty snappy.
As part of our automated test framework we include performance tests for some medium sized spreadsheets (in the order of thousands of cells).
I'm interested to know - what particularly is slow? If you have example spreadsheets that demonstrate this they would be helpful for our next round of performance optimization.
All the best,
Saturday, February 16, 2008
Hmmm... and to reply to some of the other points.
Jython is generally seen to be quite a bit slower than CPython (I don't have any specific metrics - sorry), but still faster than Ruby so probably 'fast enough'. ;-)
IronPython, by *most* benchmarks, is faster than CPython in some cases and slower in others. It is faster than Jython.
There was an interesting thread on comp.lang.python recently about IronPython/CPython performance (with some very sage advice about interpreting benchmarks):
BTW Resolver One *is* slow to start-up. This is a combination of IronPython startup time and slower [than CPython...] imports (even though we use precompiled binaries). Not a lot we can do about it at the moment, but it is definitely something we will revisit (perhaps try to import less by pulling out some unnecessary dependencies). :-)
Saturday, February 16, 2008
And to reinforce the general point that performance depends much more on algorithmic efficiency than language/platform choice: the difference in performance between Jython and IronPython is likely to be down to implementation choices rather than saying much about the udnerlying VM.
IronPython (and the DLR) accesses native .NET objects using a 'one true object' metaphor (i.e. *without* wrapping but by customising attribute access) whereas (I believe) that Jython wraps objects. The wrapping approach has a much higher performance cost.
Monday, February 18, 2008
I use Jython in an Eclipse-based rich client application. My code base started out as mostly Python and is now an even mix of Python and Java.
I used Python almost exclusively when prototyping the application and still code in Python when prototyping new functionality, especially GUI functionality, when I have to use a certain amount of trial-and-error. I decide on a class-by-class basis whether to implement in Python or in Java. I use Java for declaring interfaces, for performance-sensitive code, and for code that I know will be stable. The ability to use Python for working with unstable functionality has been an enormous boon and has sped up the application development process immensely.
On the down side, Jython's Java platform integration isn't as perfect as it could be, which complicates the use of standard Java deployment and modularity techniques. First, Jython expects to load Python source files from a path, just like Python, which means that the files must be present on disk in a location that can be determined by the application. This turned out to be only a minor hindrance for me, but I expect it would be a show-stopper for a web start application or an applet. (There is a compiler, jythonc, which is supposed to solve this problem, but it is deprecated.)
Second, it can be difficult to use Jython with frameworks that have complicated classloader schemes, as Eclipse does. Eclipse uses classloaders to enforce visibility restrictions between plug-ins, and as a result I was forced to put all of my code into a single module. It's asking a lot for Jython to interact well with this kind of wizardry, but it's a requirement for being a first-class citizen on the Java platform.
Third (and this is a pretty minor quibble), the handling of basic types like strings and maps could be better. Python maps and strings support different operations from Java maps and strings, so you have to keep careful track of types. Jython provides some automatic translation and wrapping, but it isn't universal. I think this is on the plan to fix in the next major release.
The final problem I had with Jython is my own fault. Sometimes I lost track of types when programming in Python and get locked in trial-and-error debugging to figure out the types of the values being passed around in complicated sections of code. This was usually the result of programming in Python with a Java mindset. When Java habits and style leak into your Python programming, or vice-versa, you can get tied up in knots.
I haven't been bothered by the performance of Jython. It's slower than Java, no question, but it's easy to reimplement hot spots (no pun intended) in Java code.
Overall, using Jython was a win. It certainly isn't trouble-free, but Python's superior readability and ease of development is worth the difficulty.
Tuesday, February 19, 2008
Sorry, a small but significant correction: Where I said, "... as a result I was forced to put all of my code into a single *module*," I should have said, "... as a result I was forced to put all of my code into a single *plug-in*."
Also, I'd like to add that if you plan on doing *any* mixing of Java and Python code, or if you expect to use Java libraries, you'd better have a decent grasp of Java.
Tuesday, February 19, 2008
Two Resolver One staff has taken time out of their busy life to contact me solicitating inputs about their product. If that's how on top of things they are, I wouldn't be surprised at all if performance continue to improve. So don't take my word (on performance on a Pentium 4 1.8Ghz) for it. Try it yourself and keep in touch with them.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz