Java Vs. C#: Which Performs Better In the 'Real World'?

Nerval's Lobster writes "Software developer Jeff Cogswell writes: 'Let's compare Java and C#, two programming languages with large numbers of ardent fans and equally virulent detractors. I'm not interested in yet another test that grindingly calculates a million digits' worth of Pi. I want to know about real-world performance: How does each language measure up when asked to dish out millions of Web pages a day? How do they compare when having to grab data from a database to construct those pages dynamically? The results were quite interesting.' Having worked as a professional C# programmer for many years, Cogswell found some long-held assumptions challenged."

Comments

Language is hardly relevant

[InterBigs]

When talking about large-scale websites the language is hardly relevent. There are as many high-traffic sites running on C#, Java, PHP or whatever. When facing large scale other factors play a much larger role. The only exception is when you're talking Facebook or Twitter scale: Facebook has practically reinvented PHP and also has some parts of their code in C (or C++, not sure) and Twitter made a switch from Ruby to Scala in order to handle the onslaught of users. The results mentioned in the article (accepting 2000 requests takes 600ms longer when using simple code) are not that interesting in this context.

Re:Language is hardly relevant

[QBasicer]

This is more a comparison between runtimes and servers, and less about language.

The reason this is interesting, is it's a very simple test, and hows the maximum performance. Requests can never be faster than returning a simple string. CLR + ISS is slower than JVM + Tomcat. Unfortunately, we don't know where exactly the performance difference lies.

Re:Language is hardly relevant

[cod3r_]

Assembly is the only way to go when it comes to database oriented web apps.

Re:Language is hardly relevant

[samkass]

It's also interesting to note that all tests were done on Windows. Despite him using Tomcat for Java and IIS for C# because that's the "typical" usage, he then completely does an about-face and deploys the Tomcat on Windows-- a configuration I've actually never seen and which has to give C# a bit of an advantage as the vendor-supplied OS. And yet Java still won when talking about doing anything substantial...

Re:Language is hardly relevant

[PhrostyMcByte]

C# 5.0 (the latest version) has language-integrated async functionality that makes writing vertically scalable software a snap. It looks and behaves almost exactly like sync code, but actually runs async. Talking about server-side async here, not client-side.

Doing the same thing with Java or an older version of C#, where you have only the base libraries to help you, is really quite tedious to do properly.

So, for a test like this involving web development, I'd say language is actually a pretty relevant topic. Unless you've got lots of money to spend and can throw more hardware at something, the kind of perf improvement that can be provided by this is pretty astounding.

But, there are problems with this test. He says explicitly that he's looking for a real-world test, but then goes and basically times a Hello World. There is no database access, no concurrent users. No real-world anything.

Re:Language is hardly relevant

[squiggleslash]

No, that's not fine tuned enough. Standard practice here is to program an FPGA to do the less important work, with wire wrapped transistors doing anything that needs to perform well.

Anything less is, well, lazy.

Re:Language is hardly relevant

[squiggleslash]

I've seen Tomcat on Windows a lot. Remember that most Enterprise environments until relatively recently used Windows for everything, but also bought into Java as the development platform to standardize on. Developers would be required to develop Java under Windows, and the Gods of IT would refuse to countenance a Linux server in their server room even if the developers wanted Windows.

RHEL's rise has changed things somewhat, but it's still a common combination.

Re:Language is hardly relevant

[Anonymous Coward]

The reason this is interesting, is it's a very simple test, and hows the maximum performance. Requests can never be faster than returning a simple string. CLR + ISS is slower than JVM + Tomcat. Unfortunately, we don't know where exactly the performance difference lies.

Nope, maybe that's what author think's he's doing, but he clearly doesn't understand the stacks.

For .NET, he's using the entire ASP.NET MVC framework to return a simple string. For Java, he's just using a bare servlet, and no framework code. To make this a fair test, he should be using Spring or something on the Java side.

Re:Language is hardly relevant

[darjen]

I been a Java developer for 8 years, worked at several different consulting companies and large in-house corporate environments. I've never seen Windows+Tomcat being used in an actual production setup. For development, yes, almost always. But Linux+Tomcat is much more common for live servers in my experience. At least it is in today's business world.

Re:Language is hardly relevant

[sideslash]

At my shop we engineer universes to produce all desired output at the exact moment it's needed with zero latency. It's a highly parallelized operation. Unfortunately, we currently occupy one of the universes that got mostly wrong answers.

Re:Language is hardly relevant

[Anonymous Coward]

Unless you're running Facebook or Twitter, the odds are that you don't really need to be asking questions like this. The bottlenecks you encounter are more likely to be poor code within your codebase than anything intrinsic about the language.

If you are running a site like Facebook that needs to scale beyond what that platform can realistically cope with, and your codebase is perfect and can't be made any faster, then it may be more feasible to do what Facebook did with PHP and fix the platform, rather than to switch to something different as that would involve rewriting your entire codebase, at which point you no longer have "perfect" code any more, and you lose the benefits of your dev team's existing skillset.

But very few of us are ever going to be in that position. Facebook did what the needed to do given the circumstances, but the rest of us should just concentrate on improving our own code before criticising the platform we're using.

Bottom line: If you write decent code, it doesn't matter what language it's in; all the major platforms are perfectly capable of running a high traffic web site. Conversely badly written code can and will bring even the most resiliant of servers to its knees. It's all about your code, not about the platform.

Anyone who tells you otherwise and says "language X isn't capable of doing that" is being a language snob. Feel free to ignore them.

Re:Language is hardly relevant

[TyIzaeL]

You must not work in the education sector. PowerSchool is becoming quite popular in many districts (at least where I live) these days and Windows and Mac are all they support. They most commonly set up Tomcat + Oracle on Windows servers.

Re:Language is hardly relevant

[Anonymous Coward]

Dueling useless anecdotes.

Re:Language is hardly relevant

[SJHillman]

If you measure efficiency in terms of average revenue per line of code, it's hard to beat MS. I mean, look at Vista, it was a single line of code calling bluescreen.bmp and it made them millions.

Re:Language is hardly relevant

[Anonymous Coward]

Yay PowerSchool. For over a year, they didn't even support sFTP. Most of their customers transferred student data over the Internet with no VPN using FTP. Should have seen all the SSN, name, and address data for both students and teachers that was transferred. Not to mention their data is messy.

Re:Language is hardly relevant

[Anonymous Coward]

I've been doing Java development for 15+ years and most of that in web apps. Production deployments to Linux, mainframes, and Windows. Sadly, most often, the production machines are Windows. A typical argument is that it is best to have the production system similar to development (and QA, and integration testing, and user acceptance testing) system to avoid surprises as the build travels through the process.

Concerning portability of Java across platforms, I can only recall having three issues and they are all related to file systems: paths (developer assumption), permissions, and Windows misreporting file creation time. For Java web apps, your portability issues are the same regardless of language--the browsers.

For a true comparison of Java to C#, I can only think of one way to do it. Give four weeks of identical requirements to two teams, one of C# fanbois and one of Java fanbois. Limit them to three development weeks each, and then judge by features completed and application performance. Switch teams and complete the job. Try a larger project to flush out the architecture set up phase and then adjust your results by availability of skilled resources in the market.

Re:Language is hardly relevant

[Anonymous Coward]

At my company we travel back it time and tweak the early universe to give the appropriate settings in the present day. It's currently optimised for cat videos which is probably why your settings aren't working.

Re:Language is hardly relevant

[Anonymous Coward]

> I've never seen Windows+Tomcat being used in an actual production setup.

Then you haven't seen shit.

Re:Language is hardly relevant

[Samantha Wright]

Isn't there a free implementation of that in Emacs?

Re:Language is hardly relevant

[asliarun]

No, that's not fine tuned enough. Standard practice here is to program an FPGA to do the less important work, with wire wrapped transistors doing anything that needs to perform well.

Anything less is, well, lazy.

From what (little) I know, that's exactly what data warehouse appliances like Netezza and Teradata do. They have custom built FPGAs to do the SQL execution significantly faster than what a CPU can do.

Re:Language is hardly relevant

[Anonymous Coward]

Sorry to burst your bubble, but Pearson is a private company. It is not an academic institution. You can blame this on bureaucracy in large institutions making bad choices, but teachers don't get a say on this stuff. The leadership does.

Re:Language is hardly relevant

[swb]

You've never been in education, have you? It shows.

"Educators" are the actual teachers. They have near zero say in what systems get selected, and those doing the selecting seldom have any experience in being an educator, and usually the selection committee ("Committee Decisions: Because you can't fire the committee") is judging the software on features and functionality, not on underlying technology.

If there is someone in a specific educational organization who has specific architectural biases against Windows, I can assure you they have nothing to do with system selection, only implementation.

And what are the VIABLE alternatives? Professionally I've worked with several educational institutions that have made a run at being all Macintosh, and it has always been a dismal and expensive failure on the back end. They all migrated to Windows servers and kept Macs only for teachers and students, if that.

Linux may be viable for some functions, but with most of these things it boils down to dollars. Linux may be "free" but support isn't, and finding people who can support it is expensive for school districts, at least a datacenter level and not a kludged whitebox install level. Maintaining an all-Linux backend usually requires a lot of high level administrative support and the administrators I can guarantee you are looking at COST first THEN functionality and they will ALWAYS see a Microsoft-based solution as inherently cheaper "because we already do that."

Re:Language is hardly relevant

[Beetjebrak]

That comment was actually better the second time I read it.

Re:Language is hardly relevant

[benjymouse]

We have the @Asynchronous annotation in Java 6 that pretty much does the same thing.

No it does not do "pretty much the same thing". Not even close.

To start with, the @Asynchronous annotation is for EJB session beans only.

C# async is a generalized async capability baked into the language. C# async works with disk IO, network IO, threads or anything else that follows one of several async patterns.

The big boon with async compared to task based parallelism (on which C# async is based) comes from the capability to write the code in a pseudo-sequential form and (not least) the ability to *compose* async tasks.

Think about how you handle exceptions in a flow of, say, 3 async calls. Without language support for async you have to register callbacks or futures which will execute once the previous task completes. How would you go about defining an exception handler that covers all 3 calls? You can't; not without some serious wrangling with closures and state machines.

Now think about how you would create a loop over async task #2. You cannot span a single while loop across the task call because the task will call back to a continuation function which syntactically needs to be *outside* the loop.

Now combine the loop with the exception handler. In Java this gets so unwieldy that it is next to impossible. In C# it is trivially easy and reads like sequential code:

try{
        var res1 = await FirstAsync();
        while(someCondition) {
              await SecondAsync(res1);
        }
        var res3 = await ThirdAsync(res1)
} catch (SomeException ex) { ...
}

GP is correct, the async continuations is C# are pretty unique at this point.

Re:Language is hardly relevant

[stenvar]

Maintaining an all-Linux backend usually requires a lot of high level administrative support and the administrators I can guarantee you are looking at COST first THEN functionality and they will ALWAYS see a Microsoft-based solution as inherently cheaper "because we already do that."

That's utter nonsense. In reality, Linux is no harder (and probably easier) to maintain than Windows: it's less complicated, its interfaces and tools change less over time, and there are numerous ready-made, turnkey server solutions that you basically just boot up and use. More CS grads will know and will have administered Linux systems than Windows systems because administration for Linux systems is much more similar between single user and multi-user.

School administrators may choose Windows because they believe it's easier to maintain, but they are mistaken.

They are both as good

[hsmith]

As your worst developer on the team.

I've used both and really haven't seen issue with either. I have a slight preference for C#, personally, but it all comes down to your design, architecture, and implementation that will slow you down.

Re:They are both as good

[ImprovOmega]

Eclipse is the emacs of the IDE world. It tries to be everything to everyone - infinite customizability, plugins, addons, tweaks you can make...it is at the point where for a new user it is really difficult to get a starting point to go from, and finding simple commands can be a PITA to find since they're in non-obvious (unless you've been using Eclipse for years) places.

NetBeans does a better job of exposing the functionality you need, though the extensibility is more limited (like vi or nano).

Does it matter.

[Anonymous Coward]

I personally would expect one to win in some regards and the other to win in others. My concern is that C# is too tightly bound to MS platforms. Java isn't perfect, it isn't the write once run everywhere that was promised, but the port from Java on MS to Java on Linux, Mac ... will most certainly be better.

That is enough that I would prefer Java over C# on my projects. Of course there are always outside parameters that might be enough to tip the scale.

Re:Does it matter.

[i kan reed]

On the other hand, C#'s syntax has ruined java for me. Many simple tasks in java feel like they take 3 times as many steps as they need to: e.g. overloading a method with an optional bool defaulting to false requires actually writing a new overload and passing the default. To be fair, there are times when python or a functional language makes C# feel the same way, but java is just too far removed on the convenience factor for me.

Re:Does it matter.

[hsmith]

I'll give it to MS, they have moved the language forward. Linq is amazing. Oracle has just isn't pushing forward as MS has done.

Re:Which one is the bigger security threat?

[clark0r]

This would be the browser plugin you're talking about? Websites are not served up by browser plugins. Stop spreading lies.

Just do it all in C++

[scorp1us]

Before I get modded troll, I'd like to point out that there is a really awesome C++ toolkit for web development and it will blow your mind. It's called Wt and it makes your applications fully OOP and a joy to develop in. One really awesome feature is that it is Boosted and another awesome feature is smart with regard to data. It will use where apropriate (usually you use the AJAX version of a control or mark a function for export to javascript) AJAX rather than statically filling your page. The result are some really easy to code fast websites.

These tests were also simple

[ranton]

These tests were also just as simple as calculating Pi a thousand times. Based on the description, I was hoping for some tests where a website with a dozen or so complete views with significant bindings were created in both Java and C#. Instead it was just an HTTP request or a page that printed the date.

Different frameworks and web servers are going to use varying amounts of overhead, so simple tests really only calculate that overhead. If you are going to provide benchmarks that actually have some meaning then they need to test complex enough behavior to mimic real world usage.

These tests basically just show that Tomcat is faster than IIS for simple scenarios, or perhaps that ASP.NET MVC 4 adds more overhead to page requests than JSP does. Whether this overhead is meaningful when you are processing rich real world web pages is not covered by these tests.

Nothing to see here

[MojoRilla]

This article was obviously written by someone who has no idea what the state of the art is in performance web serving. If you know anything about high scale web technology, skip it.

Where to start complaining? Don't roll your own http server. You probably don't understand what you are doing, and you will get weird results. Using Windows as a platform for a java web server is pretty silly. The author incorrectly assumes that because the .Net framework is fast, the ASP.net framework will be. That isn't the case. Running load testing on hello world test cases is silly. If you are interested in the real world, try testing with real world applications. The author also doesn't seem to understand that the JVM or .Net runtime will compile bytecode using JiT methods (Just in Time compiling). Finally, if you have skilled developers, it doesn't really matter what language you use. Architectural issues like data storage and caching are much more important than language.

Summary:

[140Mandak262Jamuna]

Test 1: a low level function, usually done by the http server, is written by the user in java and c#. C# beats java handsdown.

Test 2: A function to generate a "full web site", (actually a simple web page with all the elements and trivial content). Java beats C# hands down.

Conclusion:

1. The testing guy has absolutely no idea of how to write low level function efficiently.

2. The testing guy's idea of a "full web site" is woe fully inadequate. He could have been the guy designing "full continental breakfast" in Roach Motel Inc.

Re:Android uses Java, at least Dalvik java

[squiggleslash]

* Dalvik is not Java. While the Java programming language is available for Dalvik, together with a subset of the J2SE library, the runtime itself is unrelated.
* Windows 8 Metro "does not use .NET" is kinda meaningless, neither does Win32. However, you certainly can build Metro apps in .NET. http://blogs.msdn.com/b/dotnet/archive/2012/04/17/net-for-metro-style-apps.aspx
* The comment about the author of the article testing Java "by using a C# client" is bizarre and misleading. A language had to be picked, with the choice having the same impact on both tests. Chosing to test a Java server with a Java client, and then a C# server with a C# client would cause the test to be different in both situations and render the test results invalid.
* The author of the article concluded that Java was generally faster than C#, not that "it was a dog".
* Other than that, your comment is completely 100% correct. Possibly. Or maybe I didn't check.

Choosing a Language

[RedHackTea]

Today, most of (if not all) the reasons for choosing a language are subjective instead of objective (not objective-c). Languages are so similar (at least the fundamentals, not talking about Brainfuck-lang here) that you pick a language based on the platform it targets or just personal feelings.

In short, the Microsoft fanboys avoid more Linux-favored languages (and don't even think about Apple languages); Apple fanboys avoid more Microsoft-favored languages; and Linux fanboys avoid more patent-encumbered, closed-source languages and ones requiring to purchase an IDE/etc. for development. All fanboys avoid what they perceive as "diseased languages" like the plague. However, they will still touch these diseased language every now and then because either they have to for a job or out of pure curiosity.

Being a Linux fanboy, C# is my bubonic plague. This is also in part growing up using Microsoft Visual Studio 6 for C++. For the haters, I actually loved this IDE, but then I found out that none of my code would work on other platforms or even other compilers with Win32 such as Borland++, g++, etc. (we all remember how a variable in a for-loop wouldn't be contained to just that block... terrible). And then when exploring other languages/environments, I couldn't believe my eyes when I could actually see library-level source code -- you have no idea how useful this is. Even though I'll admit that Microsoft has gotten a little better about this (although they still tried to spread FUD using the DroidRage campaign), it's not worth it to me. They've already lost my faith in them as a customer, and I can't see myself ever returning.

Now, a good study would be to remove all of this and determine what languages are either faster to code in, easier to debug/maintain/extend with enterprise-level code, or more readable. But would this study even be useful? The differences would be so minute. Scripting languages are going to be faster to code in, so what's the fastest scripting language to code in? Object-oriented languages will be the easiest to debug/maintain/extend. As for readability, who knows? It's so subjective. We'd have to get a large, random sample size of people that have never seen a programming language before.

Having said all of this, I still appreciate this guy doing the study. Apache has always made top-quality code, and it's good to see that TomCat lives up to it.

Finally, as for sheer speed (and needs to be at least easier than assembly), C will always win.

Re:are they serious right now?

[0123456]

Open Office is slow as hell.

Repeat after me: Open Office is not written in Java, though it uses Java for some optional features. Yon don't even need Java installed to run Open Office, and disabling Java does reduce Open Office startup time since it no longer needs to start the JVM.

But it's a good meme to keep repeating, because when someone says 'Java sucks because Open Office is slow' and they're not talking about startup time, it's a very good indication that they have no clue.