Slashdot Mirror
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."
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.
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.
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.
I have seen it often said that when a slashdot headline ends in a question mark then the answer is no.
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.
-- All that is necessary for the triumph of evil is that good men do nothing. -- Edmund Burke
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.
.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.
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
"Real World?" If we're all not in the real world then we must be living in imaginary space then. Seriously, I see the C#/Java thing coming down to a matter of enterprise choice vs. performance of the language. You'll find big shops running WebSphere/Weblogic and those running JBoss to deploy enterprise apps. There's still a lot of folks deploying with tomcat, which is a great tool. Microsoft has done well over the past few years in improving IIS / .NET scalability where it now can compete with Java EE deployments. 5 years ago you couldn't say that but now the differences are becoming more narrow. I like Java and use it. I like C# and use it as well. My biggest concerns with both is that largely, they're in the hands of two very large vendors. Java has at least more open push on it but again, Larry Ellison will dictate largely what happens to Java and IMO he'll milk it for every penny he can get. C#/.NET not only sells OS licenses for MSFT but it also gets used as a toy as well.
It would be really nice I guess if both of these were truly in the public domain as to prohibit Oracle and MSFT from having direct control over how the languages evolve and are licensed.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
* 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. .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
* Windows 8 Metro "does not use
* 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.
You are not alone. This is not normal. None of this is normal.
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.
The G
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.
Um, no. You could probably write an entire office suite in perl and have it fit onto a few small pieces of paper when printed out; but nobody would ever understand it, probably not even the person who wrote it in the first place!
char*f="char*f=%c%s%c;main(){printf(f,34,f,34);}";main(){printf(f,34,f,34);}
I can't speak to C#. But I've written code for a financial exchange in Java with p50 response times around 100 microseconds. p99's are tricker but were still sub millisecond (mostly due to the GC, however we were moving toward zero GC's). Having said that, most developers who write Java would have balked at the unsavory things we had to do to achieve that speed.
I believe we undervalue the effect of the culture associated with languages. My experience is a lot of Java code is utter crap because the community is self reinforcing of bad ideas. I suspect that competent and motivated developers can take either Java or C# or C++ or whatever and make them fast.
I think in the end the system should have written the critical path in C as it has the right level of abstraction needed for low latency. Java or any other relatively high level language is great for supporting systems.
Well gee, let's see. I can definitely say that C# programs do not perform as well on OSX, Linux, or IBM I.
Proverbs 21:19