kontrawize

I can still remember when native code was faster than Java ...

I started writing programs in Java in the early days in 1996. Back then, native code (compiled for a particular CPU and operating system) was faster than (Java) virtual machine code, but Java let you run your program across multiple platforms with having to tear your hair out, and that was sometimes more important than raw speed.

A few years later, people started to challenge the prevailing assumption that native code is faster. The thing is, if you have infinite time and resources to write your code, you can make a program faster by using native code. However, in the real world, no-one has that luxury. When things have to be done within budget, by a particular deadline, it changes things significantly.

With Java, you finished writing the code earlier. That gave you more time for testing, debugging, and performance optimisation. Mike Kay gave a great presentation at a conference on how virtual machines are delivering on performance. With native code, once it is compiled, that is it. It runs as fast as it runs. The only way it will run faster is if you move it onto faster hardware. With virtual machine code, it's different. Mike produces the Saxon XSLT engine, which is written in Java. He pointed out that with each new release of Java, the virtual machine gets faster. Your programs run faster, even on the same machine. This is because new optimisations can be introduced between the virtual machine code and the native code that is dynamically generated when Java runs. For XSLT stylesheets, you also get speed improvements as the XSLT engine is improved and optimised. So you have multiple layers of optimisation that are making your programs faster and faster, without your having to change them.

But, does this really work in practice? I have to admit, I expected Java programs to eventually be fast enough that the extra speed of native code wasn't worth the trouble. Yesterday my limited expectations were blown out of the water. I was doing a small XML task, regrouping the information in a document into a different structure. When I do XML to XML transformations, I usually use XSLT, because it's the quickest and most straightforward thing to write. XSLT 2.0 makes it easier to do grouping transformations than XSLT 1.0, so I was using XML Spy 2005 to write and run a suitable XSLT 2.0 transformation. Eventually, though, I found a bug in Spy's implementation of grouping functions (specifically, "current-group()[1]" returned an empty sequence even when "current-group()" was non-empty).

I switched to my laptop where I have the oXygen XML/XSLT editor, which is written in Java. I selected Saxon 8B as the XSLT 2.0 engine. It ran the the stylesheet correctly, but more importantly, it ran at least ten times faster than the native code implementation in XML Spy. Now, that is something I wasn't expecting. This is the first time where I have seen a huge performance boost by moving from a native code solution to a Java solution.

What does this all mean? Well, I'm not suggesting that Java programs are always faster now than their native code equivalents. That isn't the case. What I am suggesting is that it is no longer valid to assume that native code solutions are faster than Java (or other virtual machine) solutions. Some solutions will be faster than others, but you won't know if native code is faster or slower than virtual machine code now without actually testing it. That is a significant change, which impacts the way architectural technology choices are made for projects.

By the way, in XML Spy's defense, it's XML diff tool handles much larger documents than oXygen's without running out of memory. The native code solutions aren't going away. It's just that they can no longer claim an automatic performance advantage.

[ Technorati tags: software architecture, Java ]

More comments on comments

Quite a few comments in the last day, so here's a quick roundup of some of them.

Poor and Stupid

Yes, Apple's iCal is not an option for me, because I don't have a Mac. It's not enough for me to buy a Mac for. When Intel-powered Macs arrive, if it becomes possible to run Windows and Linux in virtual sessions on a Mac, I'll definitely think about the possibility.

I agree that timezone support in many calendars is weak to non-existent. The calendar on my old Sharp Zaurus PDAs actually supported timezones, which was very useful for trips to faraway places, or for setting the times for teleconferences correctly.

I do use Subversion for version control, and I agree that calendar files on a file server can work for a small group. However, it's still a bit of work without the right calendar application.

What I have done in the interim is to set up a Yahoo! calendar, and install the new Yahoo! Go application on my (Nokia) mobile phone. This synchronises my calendar, contacts, and e-mail between my phone and Yahoo! It's very neatly done. OK, so I don't have an offline calendar on my laptop, but I have it on my phone, which is sufficient.

Iron Python

Apparently Microsoft's BizTalk is written completely in .NET. Cool. That was one I didn't know.

Poor and Stupid

I was amused to read Tim Bray's conclusion that PHP is part of a plot to force everybody to replace their old PCs with powerful new servers. When I lived in Germany in the early 90s, my boss there told me that there had been a historical agreement between church and state in Europe: the church promised to keep the masses stupid if the state promised to keep them poor. That was, of course, meant to cement the positions of both.

At the time, it was suggested that this Machiavellian relationship between church and state had been replaced by the similar relationship between Microsoft and Intel. After all, what possible reason could there be for all the stuff they keep adding to Windows, except to slow your PC down enough to force you to buy a new one? Well, I don't really buy into conspiracy theories, but that one remains a popular one to this day. Let's see if Windows Vista will run on your existing PC, or if the new GUI will force everyone to upgrade.

By the way, I share Tim's dilemna about finding a good calendaring solution. I also want a solution

• that will let me share a calendar with a few colleagues;
• which is available offline when my laptop is offline;
• which can be synchronised with my phone calendar.

I don't use Microsoft Outlook or any similar combined calendar/e-mail program; I would prefer something stand-alone, or perhaps integrated (loosely or tightly) with my browser (Opera). Oh, and if the central calendar had an Atom or RSS feed, so that I know where to look for the latest changes anyone has made, even better (although, for a large number of users, you would need some filtering).

Let me know if you know a good solution. I don't yet have one, and I don't really want to write one myself. Life's too short.

IronPython - a Serious Challenge to Java?

I see that Microsoft has announced the beta release of IronPython, their port of the Python language to the .NET platform. This could be one of the biggest threats that Java has faced so far.

In many ways, .NET and the C# programming language are a homage to the success of the Java virtual machine and the Java language and API. C# has a lot of Java's features, although the latest version of Java (5.0) returned the favour by copying many of the features that were unique to C#.

The thing is, if you use Java now, there isn't a compelling reason to move to C# and .NET. The differences are too small. If you use C# and .NET, your reason for moving to Java would usually be because you want to run on a non-Windows operating system (e.g. Linux). However, Novell's Mono implementation of C# and the CLR virtual machine gives you the portability (and credibility) to use C# for cross-platform applications too. It's all very evenly matched.

Throwing Python into the mix makes it interesting. Now, there is a version of Python for the Java virtual machine (Jython), but it's use is limited. Java developers don't really think Python is worth the effort, and Python developers tend to use Jython only when their customers insist on a Java-compatible solution. Python on .NET is more interesting because it is closer to the way Python works normally. Python has its own virtual machine, but is easily able to call out to native C/C++/etc. code to get the benefits of its functionality and/or performance. In principle you can do this from Java, but it is frowned upon (Sun ran a 100% Pure Java campaign for a while in the earlier days of Java, which meant that you can link to native code, but don't, except as a last resort). The idea of having a virtual machine, but with access to native code, is also fundamental to .NET.

There was a time when Java was the programming language you used when you needed to deliver the result quickly (certainly more quickly than using C/C++). Now what I see is that Python has become that language, although it's facing a growing challenge from yet another language, Ruby, which seems to be the latest darling of the quick delivery crowd. That said, Python has become very well established of late (it's older than Java), and Microsoft's IronPython port can only raise its profile and increase its penetration into the enterprise end of IT.

Now, will Microsoft deliver any software written in IronPython? That would really make a difference. To date, they have been slow to deliver anything written in C#/.NET, but that should change when the next version of Windows, Vista, arrives. Might they use Python? It will be interesting to see.

[ Technorati tags: software architecture, Java ]