Price of performance

I KEEP UP with trends pretty well, but sometimes the train makes it to the next station before I realize I should be on it. When server-side scripting, VB (Visual Basic), and Java first rose to prominence in the ’90s, I couldn’t understand why anyone would run software that put such a strain on the server. My C++ programs ran many times faster and used far less memory. Looking back, I was embarrassingly smug about it.

What shut me up was Microsoft’s ASP (Active Server Pages) and the JScript language. The time I saved in development more than made up for the run-time performance loss. After working with ASP, PHP, and other scripting languages, I came to understand and appreciate Java. My long-standing prejudice against VB vanished just in time for .Net to make its debut. It was built to be safe, secure, stable, productive, and portable across platforms, just like Java — and I liked it immediately.

Moving performance to the back burner in favor of productivity and usability has transformed enterprise software. Not only are projects getting out of the gate faster, but the languages and frameworks are evolving at an incredible pace. The indirect benefits are many. We use XML to create data files that humans can read and edit, accepting that it takes the server longer to digest them. When you call out to a Web service, you don’t worry about how fast it answers; you’re just grateful you can hit it from where you are.

Now that I’m comfortable in my seat on the “productivity, interoperability, and safety trump performance” train, I hear another whistle in the distance. Microsoft is working to quantify .Net’s run-time speed advantages over J2EE. If such tests help vendors tighten up inefficient code, everybody benefits.

My concern is that this experiment could escape the laboratory. I wouldn’t want to see businesses add benchmark performance to their framework selection criteria. Web services’ deserved ubiquity can’t happen if vendors start bashing one another about how many thousands of calls they can turn around in a minute. I lost a couple of years of productivity to my obsession with the stopwatch. I’m loath to see server software vendors turn back in that direction.

I’ll wait to see how this plays out, but I will make one pre-emptive statement. Of course .Net outperforms J2EE: When you target as few server architectures as .Net, you can optimize for each of them. .Net calls into a fixed set of OS-level enterprise services written in C and C++; J2EE’s modular services, or at least the interfaces to them, are written in Java. Microsoft invested a lot of effort in optimizing .Net’s native-code interoperability layer, a task that would have been impossible if .Net tried to match Java’s platform reach.

When I discussed this with InfoWorld Test Center Lead Analyst Jon Udell, he cut right to the heart: If Microsoft wants to drag race with J2EE, it should use Rotor (the BSD-based shared source edition of .Net). I can’t be more succinct than that.