Java Vs. C#: Which Performs Better In the 'Real World'? 437
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."
Re:Which one is the bigger security threat? (Score:5, Informative)
source: experience (Score:2, Informative)
C# programmers get paid more.
Just do it all in C++ (Score:5, Informative)
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.
Summary: (Score:5, Informative)
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:Which is better bad or worse? (Score:4, Informative)
Re:Language is hardly relevant (Score:5, Informative)
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 (Score:4, Informative)
The official Tomcat installer for Windows (as in, the one that you'd download from tomcat.apache.org [apache.org] installs the Tomcat Native Connector, which improves performance considerably. And there's a lot of vertical market applications for Windows that bundle Tomcat.
Re:Language is hardly relevant (Score:2, Informative)
Facebook has significant parts in C++, and employed people like Andrei Alexandrescu [wikipedia.org] to do some of the heavy lifting. He has given some talks with regards to computational efficiency in C++ for Facebook, based on his work.
Re:Language is hardly relevant (Score:5, Informative)
Re:Language is hardly relevant (Score:5, Informative)
Re:Language is hardly relevant (Score:4, Informative)
Threading is a form of async, but not the one I meant.
I was referring to async I/O, where you can request the OS perform some I/O and then notify you when it's complete without blocking any of your threads. This enables you to write apps with co-operative multitasking where you switch between tasks while you wait for I/O, which is far more efficient than switching between threads.
With this model you can (somewhat) easily service 10,000 clients per-thread.
Typically this form of async is done using callbacks or eventing, which is doable with some practice but creates code which is really gnarly to anyone lacking experience with async. .NET has supported this form of async for many years, and I believe Java's NIO library provides the same thing.
C# 5.0 takes it a step further and gives an incredibly useful syntax sugar -- basically hiding all the callbacks, making it look like a simple synchronous method. Behind the scenes, the C# compiler generates a state machine class that does all the heavy lifting.
Re:Language is hardly relevant (Score:4, Informative)
Overall, I'd say the test showed that the author doesn't know how to benchmark.
IIS sucks pure and simple. Even on Windows I use Apache. It's just better.
But I also noticed, he spent a lot of time and effort 'breaking the rules' to make Java better, and working to make it more efficient, but he didn't do that for C#.
So we have... Java's raw implementation is slower than C#s
But when combined with a server, Java Tomcat (still Linux? Or is it back to Windows) is faster than C# on IIS/Windows.
No shit shirlock, really? Might as well add Python and ModWSGI on Apache then. Have, what is usually regarded as the performance king, in the comparison.
I think just about everyone knows, performance wise with the same hardware, a server will be faster on about any *NIX but MacOS (and probably even that) than Windows.
I think just about everyone ALSO knows that IIS is a steaming pile, and Apache is pretty damn good (IIRC TomCat is built on Apache).
Now, if we compare the raw tests (C# vs Java) C# is faster, but when we move to the web servers, suddenly Java is better. That tells me... IIS is significantly (orders of magnitude) worse than Tomcat/Apache.
That wasn't news a decade ago.
And this is article longer a comparison of Java/C#
Re:Language is hardly relevant (Score:4, Informative)
Unfortunately, we don't know where exactly the performance difference lies.
The test details are very, very light (some code would've been nice). However, just looking at the details we have, I see two issues with the C# testing in test #2 -
1) The tests were pushed through the MVC4 Framework - this is an additional layer of unneeded overhead and processing for the C# tests. It's not mentioned if the Java requests were piped through an MVC engine.
2) "I can have a servlet return some HTML, or I can return the results of a JSP page. These are analogous to the C# controller and View approaches, respectively." - This is incorrect. Servlets would be analogous to writing an HTTP Module, and JSP would be the equivalent to writing an ASPX page/HTTP Handler.
These two problems probably stem from the author's unfamiliarity with C# on IIS outside of an MVC environment.
Re:Language is hardly relevant (Score:5, Informative)
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 (Score:5, Informative)
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 (Score:2, Informative)
Ummmmm, Unix has been the server platform of choice in practically every secondary education institution in the US (one might even say on Earth) since time immemorial. It would be HIGHLY unusual to see anything with "University" in its name running any significant outward-facing IT infrastructure on Windows. Smaller and newer institutions, yes perhaps, but even most colleges that have been around since the 80's are basically Unix shops (and these days are mostly basically Linux shops, though you will still find a decent amount of AIX/Solaris/etc here and there). Not to say that Windows isn't quite common and even prevalent in some niches in the schools I've been associated with, but none of them would have had any difficulty or hesitation in running a line-of-business web application on a *nix platform, and most wouldn't have even thought about using Windows for that unless there was a specific reason for doing so.
Re:Language is hardly relevant (Score:5, Informative)
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 (Score:4, Informative)
But I also noticed, he spent a lot of time and effort 'breaking the rules' to make Java better, and working to make it more efficient, but he didn't do that for C#.
It is clear that he is a Java novice and he admits so much. He failed to do it right, both his version of HttpServer and his ServerSocket are WRONG.
HttpServer needs to be configured with a thread pool. If you fail to do that, it will run single threaded. And it is clear that is exactly what happened.
ServerSocket is the old network API from the first version of Java. It was build with the idea of "one thread for each connection". Therefore all IO calls are blocking because you are supposed to run them in threads. ServerSocket has an accept call that will block until the next connection. You are then supposed to start a new thread (or use a thread pool) and let the new thread handle the new connection. He clearly failed to do that, instead he made a single threaded implementation.
Modern Java frameworks use NIO - the new network IO for Java. This has non-blocking IO calls and allows much faster processing. It is also much harder to use on a low level, which is why most developers never do that.
All of this explains why he is suddenly having much more luck when he switches to Tomcat. This takes him away from the low level stuff that he is doing wrong. Tomcat will do the IO correctly, it will use threads. It will AFAIK not use NIO however. But just doing it right using threads will give him a speed up of order of magnitudes.
Conclusion: He was not spending a lot of time and effort on making Java better. He was trying to learn Java. Too bad that he failed. Great that he moved on to easier higher level Java.