Slashdot Mirror
Another J2EE vs .NET Performance Comparison
Starting yesterday, we received a bunch of story submissions about a
performance comparison between J2EE and .Net. It didn't seem all that exciting, and we sort of ignored the story. But as usual, it appears that some people take issue with the methodology and conclusions.
Some of us are not in a position to dictate policy. Love Linux or not, some of us will have to use .Net or look for another job.
Not a good option during these bad economic times.
The beast most of us have sitting on our desk these days is so fast as to make language performance not such an issue. What should be focused on to support the future of computing is a well-typed, well-structured language to allow programmers to think at a higher level of abstraction than previously. That's why I love Mac's standardization of Objective C so much -- it allows high-level control of programs. Performance only matters if it sucks.
But what do I know. I'm just looking for anonymous gay sex.
We used all java technology on www.bayoubid.com and had no problems with speed. In fact from our initial tests java was quicker than C#.
I mean, "...excessive exception handling"? WTF?
This only underscores the by now expected knee-jerk reaction these types of pissing contests bring. There's always some expert who can refute every single point of the whitepaper, who in turns gets dissected by someone else ad nauseaum.
In the end it's never been about benchmarks or raw speed. It's about how productive you can be writing these applications, time to "market" and total cost. It doesn't matter if J2EE is 14.3% faster than .NET or viceversa.
On a side note, I wish the 'net were never called the 'Information Superhighway.' That single analogous dubbing has spurred the acceptance of rhetoric in Congress that allows all sorts of regulation.
Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
The only things TMC actually proved are that they are
NOT J2EE experts
but they
ARE MS shills.
Everybody knows "benchmarks lie" as the old cliche goes. It's just funny that a chest-thumping "enterprise software" consultancy would so blatantly pitch a relatively un-scientific benchmark as a serious study.
Lines of code has nothing to do with ease of use, reliability, or scalability.
;-)
This isn't some sort of a 'I can do that task in *3* lines of code, Jack!' contest..
-- I'm the root of all that's evil, but you can call me cookie..
jPetStore is worth checking out. These people decided that the J2EE pet store is way too complex, which I'm inclined to agree with. They produced, using Jakarta Struts, a Java pet store web application that is much leaner. It's comparable in size to the .NET pet store but better in several ways - there's no SQL embedded in the code, there's no HTML embedded in the database, no code was automatically generated, and it's MVC-based.
I've always thought that Enterprise Java Beans are overengineering to the extreme. It's nice to have something to back that up with now. There's no question in my mind that this JPetStore beats out both the original J2EE one and the .NET one in maintainability.
They didn't do any benchmarks - performance wasn't what they were going for - but it would be interesting to see some. I'd be inclined to believe this simpler approach would also have much better performance than J2EE.
Regardless of how you argue the testing parameters, it's pretty clear the .NET implementation won out. Even if it didn't, the Price/Performance chart makes this a pretty easy pick for most businesses.
.NET stuff is cool and people should take notice. Even the evil empire can raise the bar. And competition helps us all in the end. Lower those prices SUN and Oracle!!
You can probably get much higher performance out of the J2EE stuff at the very top end, but only by running it on the 'big iron' that most companies can't afford and even fewer actually need.
M$ has a lot of problems, but this
--- Don't be a player hater: I meta-mod ALL negative mods as Unfair.
Quote from the article: It contains both errors, halftruths, and lies.
Unfortunately, the article contains both spelling errors, grammatical errors, and errors of style.
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
- The Middleware Java Pet Store 2.0 implementation uses the same basic EJB-recommended
architecture as the original Java Pet Store (except fully optimized for
performance). Hence, its code count remains largely unchanged over the original at
14,004 lines of total code.
This is covered right away in the rebuttal, as there seem to be some tricks played to get the discrepancy so large.With the .NET Pet Shop 2.0 implementation, Microsoft has done some further
optimizations to reduce its overall line count, while also extending the application with
new features for distributed transactions and Web Services. The new .NET Pet Shop 2.0
contains a total of 2,096 lines of C# code (the 1.5 version had a total of 3,484 lines of
code, a 40% reduction).
you got that backwards. Java required 14k lines of code and .NET required 2k.
this is like trying to make a race between a tortoise and a snail, only to realize that your stopwatch doesn't go over 15 minutes.
Je t'aime Stéphanie
I've heard some word (admittedly not many datapoints) that some companies are still embracing Java/J2EE, but are going for "JSPs" (hopefully a euphamism for good use of regular java objects, maybe some wrapped JDBC) instead of the fullbore EJB. In my experience, this is a very smart thing. I've had successes with using a lot of the same patterns recommended for EJB with the lighter-weight stuff, and have heard of at least 3 really collosal EJB failures.
EJB makes it easier to have physically seperate tiers, and adds enough systems-needed overhead that you'll probably need 'em...
SO YOU'RE GOING TO DIE: The Comic for Dealing with Death
...are interesting when well researched, but basically useless to anyone who would actually have to choose between these two development environments. If you work for a company that designs applications of this kind there will be a host of more important things to consider than raw transactions per machine. The simple fact of e-commerce is that if a user is actually going to buy something at your site, you can waste tremendous processing power making them happy. If you make 2 dollars profit on a transaction and had to use 20% of the CPU on a 2Ghz processor for 40 1 second bursts (like you will if they shop using RH interchange), it's still worth it. What this benchmark argues well is that the MiddleWare product is probably worth buying if you have processor constraint problems. No amount of increased performance would warrant changing a staff of experienced Java programmers into a staff of inexperienced .net programmmers. Extra processors are just too cheap....
So is it that The Middleware Company will just claim that the winner is the one that paid them? Or is it that .NET really is the performance winner whereas J2EE wins most of the other awards?
And why is it surprising that the performance winner is the one whose entire platform, from the operating system to the SQL server to the framework, is made by a single vendor? Of course it will perform better - they're all in the same building (or complex in this case).
Schnapple
OK, first off, I don't care how many lines of comments or exception-handling routines you take out, the Microsoft solution was still 7 times smaller. If a sub at two different stores costs the same $5.00, I would definitely buy the 7-inch one over the 1-inch version for the same price; essentially, it's better no matter how you cut it (no pun intended).
.NET are irrelevant at this stage in the game, and a PHP vs. ASP review would be more relevant.
Furthermore, if Yahoo moves from C++ to PHP for the majority of their Web applications, I think that's saying something. Perhaps J2EE and
Department of Physics and Atmospheric Science, Dalhousie University, Halifax, N.S., Canada, B3H 3J5
It didn't seem all that exciting, and we sort of ignored the story.
Maybe we could get a bunch of people to whip up a controversy about a benchmark whitepaper comparing performance of rcp and ftp.
"Provided by the management for your protection."
Unfortunately, the article contains both spelling errors, grammatical errors, and errors of style.
Great! The the author is sufficiently qualified to become a slashdot editor.
Anyone find it particularly hilarious that the Register couldn't even report the results correctly? Fine that they get anti-MS people to put in quotes, but the facts of the case (namely 14k lines of code for java v. 2k lines of code for .NET) were reported in reverse? Ugh... how these guys have a website is beyond me.
Starting yesterday, we received a bunch of story submissions about a performance comparison between J2EE and .Net. It didn't seem all that exciting, and we sort of ignored the story. But as usual, it appears that some people take issue with the methodology and conclusions.
So let me get this straight. A report comes out (that looked pretty fair to my eyes) where .Net kicks the crap out of Java, but that's not interesting. But as soon as someone puts out a (pretty silly IMO) refutation of said report it's suddenly interesting?
Yeah, yeah, I know -- it's Michael and it's Slashdot. But sheesh, come on.
Anyway, is anyone really surprised that .Net is going to be much faster than Java? It would be hard to make it slower, and if I were in charge of the .Net project, that would be one of the first issues I would address if I was making a competitor to Java.
Sometimes it's best to just let stupid people be stupid.
It's their business ethic I can't stand. .NET is the most exciting thing in distributed component programming since Objective-C and NeXT. Unlike, Microsoft has enough influnce to acutally make a new programming language part of the vernacular that programmers use.
.NET, and have been utterly amazed at the API. While C++ has about 50/50 curve (50% of the things are really easy to do, the other 50% suck) and Java raises that to about 70/30, C# and more importantly the .NET framework allow programmers to naturally write good n-tier applications. (In fact, my biggest critique on .NET is that it tends to force people to n-tier when that is not completly appropriate).
.NET is component oriented. Refliction, delegates, events, emission, cross domain calls and third party language itneroperability are all first class in .NET...
I have deployed two different production systems off of
J2EE is a horrific mess in many ways. The abstractions don't map well to real world concerns (for example, a bean represents a row, not a business object, unless your business object is a row, in which case you are probably over exposed to changes in the database), and the API's for SOAP et all are poor (unless you use Glue which rocks beyond anything else I have seen in Java).
Java's basic trade offs are part of the problem. Remember that Java was created for the purpose of running on embeded systems. This makes very simple tradeoffs (for example, optimizing for size in the bytecode instead of performance) that are not real good for large applications.
Finally, Java is object oriented.
Now, if Microsoft's business guys would just follow suit.
The original J2EE version of the Petstore application was meant as an EDUCATIONAL example for those new to J2EE. As such, it was not built with performance in mind, but rather was built with the mentality "How can we use every aspect of J2EE to implement this incredibly simple problem." No one in their right mind would use J2EE or EJBs to implement the Petstore app. It would be overkill in the extreme. And even if the J2EE version of the Petstore app was modified for performance, it's unlikely you'll be able to beat something that was built from the ground up with performance issues in mind. I'm sure this was the case with the .NET version.
If you want a good comparison of a .NET and Java version of the Petstore app, check out JPetstore which was built from the ground up with simplicity and performance as high priorities. Hopefully in the upcoming weeks we'll see some good benchmarks using this version instead of the J2EE version.
Blah Blah Blah
I've been building web applications since 1997. In nearly every app I write most of the time is spent gathering and sorting the data, not in presenting the page.
If one of my pages takes 7 seconds to come up, I can almost guarentee that the query is 6.x seconds. For that reason, I agree, language speed isn't that critical to me. What matters is: How easy is it to write/maintain? Will the language be supported? Can we hire guys that know it? Is it hard to learn?
That which does not kill me only makes me whinier
Therefore, it is much better to compare how both technologies help individual programmers as well as their teams to work faster and to produce a code with less errors (debugging time and QA resources). That would be a function of how API is structured, how concerns could be separated, how customizable code can be and will programmers tend to hardcode "business logic" riles.
Does anyone know such comparison of J2EE and .NET?
Less is more !
Besides that, look at the line comparison in code - the .NET version was 11,000 lines and the Java version was about 2600 lines. Clearly what happened here is that the Microsofties decided to be smart about it and write all their functions inline - not pretty but fast. Whereas the Java coders invoked class after class after class - which looks better but all the instantiations and memory allocations of classes are a big performance hit.
Why not just take an Intel chip architect and tell them to come up with something in byte code, I'll bet it'll knock the crap out of everything else!
The point is, if you created the technology, of course you're going to be able to make it faster because of your intimate knowledge. Unfortunately, I didn't create
Crowded elevator smell different to midget. -Chinese Proverb
BS stands for bullshit.
.Net. a design clearly aimed at performance and competition, MS declared their petstore is much faster than Sun's. It is a absurd and ridiculous marketing trick only MS could think out. (when they hire poople, they do ask them to think out of box by asking some stupid tricky questions, do they?)
.net one.
.Net VS two outdated version of j2ee app servers. .Net. VS linux for j2ee. (linux version of j2ee usually is the slowest one because other venders always tuned to their own hardware first, then windows, last resource is given to linux, recently IBM .Net VS using the slowest and now abandoned BMP Entity Bean for j2ee. (the new CMP Entity Bean not only faster, but also has very good cache machanism.and directly jdbc perhaps even faster if you only
a little history of pet fight.
the petstore was originally a demo application written by sun. it was a tutorial tool to demo how to use some new j2ee technologies, some best
practices and good design patterns, a 101 course for j2ee. Nothing involved to run as a real world applicaiton or optimazed for that.
then came the MS petstore for
Since it is a marketing trick targeted to nono technical managers, j2ee camp reacted by their own performance petstore, Oracle has their own version
running under oracle app server and db. I can not remember exactly the figure of the result, but it is at least 10 times faster than the
MS lost this round, they must have thought very hard for a while, now we have this new report.
The report published by TMC, the company has a web site theServerSide.com which has very high reputation in java community. MS obviously put a big money in the boss's hand and forced the report to be published. Some tricks they used now:
1. a brand new beta version of
2. using Wintel machine for
and Oracle changed their priority i think.)
3. using extensive cache for
care about the speed. )
4. MS invited to tune their application VS IBM, BEA, SUN have zero idea of this project.
5. running db and app server in same machine. (J2ee is designed for distributed computing, that is why a high overhead for EJB technology etc)
6. trying to give a impression that TSS j2ee experts joined this competation, but the fact is none of them involed. so they just fighted with a dummy made by themself.
I thought that this type of benchmark was breaching the EULA from Microsoft. But, after reading the report I found it to be legal. Since the benchmarks put .NET into a good light, then it is ok. If the benchmark put .NET in a bad light, then the benchmark is not allowed.
Fight Spammers!
Lines of code has a little bit to do with reliability. It's a well-known fact that the more lines of code you write (called SLOCs), the more bugs you will have (notes on this here). Although more SLOCs means more bugs, density of bugs does not increase with code length (IEEE report here).
You would have been jumping up and down with excitement, had the results been the other way around. Let's try to have at least an illusion of objectivity, OK?
When men used to be men
So you don't think that maintaining 2000 lines of code as opposed to 14000 makes any difference in the scalability, reliability or ease of use.
.Net application could be the best designed application that is has everything well abstracted and adheres tightly to the MVC model of programming, but I don't give a shit 2000 lines of code always going to better then 14000 if they both accomplish the same goal.
What's more scalable an application which is 7 times larger than it's counterpart? An application that new-to-the-project developers aren't afraid of because it's some big huge pile of code that takes countless hours to become familiar with.
How about which application is more reliable. Is the one that is 7 times the size going to be more reliable and be easier to fix bugs.
And our old friend ease of use. Let's see we have here 2 applications and one is 7 times the size as the other, which one will be the easiest and most fun for people to poke with a stick to fix all those annoying problems useability invariably comes up with.
Now of course the 14000 lines in the
Writing efficient intelligent code is the way to go, not Microsoft's write tons of shit code and hope for the best mentality towards the development process. I am talking out of my ass a bit here, but I think I make sense - or do I?
Peace
LoRider
I disagree. If I write an elegant solution that takes up 500 lines, and you write a clunky solution that takes 1000 lines, who was more productive?
Now if we come up with the same solution, but I just type faster, so i have 1000 lines done, and you have 500 lines done, who is more productive?
Performance of a developer should be measured in (features implemented - bugs found)/time * some_constant_for_how_maintainable_the_code_is
anything else, and you are lying to yourself.
Soooo..... When .NET beats the pants off J2EE it's not newsworthy, but when someone questions the results it is? Surely if one is worthy of posting on /. they both should be...
Did you intentionally reverse the figures? The
Why not go to the source and draw your own conclusion. I looked at the report and it seemed more than fair. This was a straight up "best practices vs. best practices" competition, using Sun's recommended coding standards.
It is helpful to note that this is the second such test that The Middleware Company performed. The Java folks squawked because the
In my opinion you can pin the blame squarely on EJB's. They are bloated, the environments are a royal pain to configure, and they are S-L-O-W. Sun recommends that people use them, so it's totally fair that it was used against them in this comparison.
Hate Microsoft if you want (I do), but you can't wear blinders and ignore the competition. J2EE blows. Get over it.
Incidentally, all this stuff was run on Windows 2000. Somebody should try it on Linux.
.NET is a lot faster
plenty of benchmarks on http://dotnetguru.org/
Yeah, I see that... from the URL.
Beware: In C++, your friends can see your privates!
There will probably be another J2EE implementation that can "beat" the .NET benchmark. However, I think there is some degree of truth to this particular one. At our .NET User Group Meeting last night, we had someone from Microsoft actually talking about this benchmark. He didn't go into much detail on the J2EE side, but said that the MiddleWare company spent 10 weeks trying to get the J2EE implementation tweaked. So either these consultants are really incompetent on the Java platform, or there really is a significant performance difference.
.NET could *ever* be faster/better/etc. than J2EE. So really, it's a religious thing and I don't think any amount of proof will convince him. And I'm sure there are certainly others out there thinking that way. Of course the other camp also believes .NET is "all that".
It's even more convincing in reading the article posted in the link (the "review" that is). Basically it was bringing up how the lines of code count was not correct because J2EE could have done a better job. Bah, that's a silly argument. LOC can't just be brushed off because it really does have something to do with the cost. More lines of code isn't just for "lazy programmers", it's also a factor when you have to think about MAINTAINING that code.
However, I do buy the argument about not using the "latest and greatest" J2EE. So, I get back to my original point.. I'm just waiting for the next benchmark.
So since the author complains about the PetStore app as being such a bad design, how about coming up with a new one and then comparing those? It seems to me like, no matter what, the author of the article doesn't believe
From their FAQ about the benchmark..
Was Microsoft involved in this, did they fund this, where were the tests done?
Yes, Microsoft was certainly involved, as the paper describes. The Middleware Company approached Microsoft regarding performing such an experiment. Microsoft provided the lab, which was located in Seattle, funded the setup costs, and reimbursed us for expenses, including travel expenses. The Middleware Company invested several man-months in this project for which it received no compensation. The activity took much long than we expected, and at various points, we also hired independent consultants experienced in appservers A and B to tune them or provide recommendations, at our own expense. The parameters of the lab were under the control of TMC. TMC controlled the testing process. TMC stated up front that TMC would write a report about the real results, no matter what they were. These experiments are time-consuming, and require resources. Without permission and some support from Microsoft, we would not have been able to conduct the experiment. We would like to have conducted many more experiments than we did, and hope to in the future. TMC stands behind the results of the tests that were conducted.
Does the fact that Microsoft gave permission for this experiment and provided some support, invalidate the results?
That is for you to decide. TMC stands behind the results of the tests that were conducted. Should there be other such experiments to be arranged in the future, we will not be able to do them without some assistance with the lab, setup, expenses, and we would hope for more support than Microsoft provided us with for this experiment.
[alk]
Anyway, such a comparison is flawed from the start. Bench suites should be developed by independent 3rd parties, or consortiums like SPEC and NOT by vendors.
I actually don't find the results surprising. Microsoft's pet store is heavily optimized for an app server/SQL server; the standard EJB pet store should work with minimal tweaking on any EJB-compliant app server / SQL server pair.
The Raven
The Raven
I disagree. If I write an elegant solution that takes up 500 lines, and you write a clunky solution that takes 1000 lines, who was more productive?
Now if we come up with the same solution, but I just type faster, so i have 1000 lines done, and you have 500 lines done, who is more productive?
Performance of a developer should be measured in (features implemented - bugs found)/time * some_constant_for_how_maintainable_the_code_is
anything else, and you are lying to yourself.
I've said it here before and I'll likely say it again. Lines of code is an absurd measure of anything. It means nothing. A 1000 line source file can be more "elegant" and more readable than a 500 line source file and visa-versa.
And as for your typing speed comment. Anybody who thinks that even 5% of programming is typing the code in has a lot to learn. Good programming is design, documentation, testing, and refactoring. Typing in code should be a relatively small part of your job as a programmer. If it's not, most likely you're doing something wrong. If you're worried about your typing speed, you're doing something wrong. If you can tell me how many lines are in a single source file you've created without checking, you're probably doing something wrong.
I've been using J2EE now for a while, and they made some hideous performance mistakes. The #1 mistake they made was BMP. BMP, for those of you who don't know, is an object persistance model where each object manages it's own storage. It's pretty obvious that for N rows of a database that map to N objects, you will need N SQL statements. That's just wrong and bad. Not only is it the slowest way to access the database, but it requires 10x the amount of code to work with. The other two (common) choices are CMP and JDBC in session beans (others are JDO and other ADO-ish Java API's that wrap JDBC). CMP would require 1 SQL statement to retrieve N rows, and requires no SQL be written, works on all RDBMS's, and you only have to write a skeleton object. It's about a magnitude of 3 faster than CMP. Directly connecting from the Session beans(pretty much a CORPBA object) will make you write your own SQL, but will increase performance yet further(since you can use stored procedures or just do mass updates and still maintain database independance).
.Net could never hold up to best price/perf. against free. JBoss may not be a speed deamon(it's not slow at all though), but if you disable debugging(on by default), use IBM JDK 1.3.0 and MySQL with innoDB, it will easily win price/performance.
.Net get a foothold, but they are loosing theirs fast.
The next thing they did is exclude JBoss, one of the most popular J2EE servers. It's open source, and easy to use. One can only conclude the intentionally left it out because
After reading that TMC had taken money from MS, the only conclusion that I could come up with is that it was rigged. No real J2EE expert would ever make those mistakes. Even free E-Books on TSS will tell you not to make mistakes like that.
Basically, this really hurts the Java community to see TMC take stabs at J2EE after all it's put into it. Either that or we are to conclude that TMC is unfit for the J2EE educational services they offer. Either way, they may have helped
Anyone that doesn't know that much about J2EE or doesn't take a look at the code will think this is like the florida recount fiasco, but it really is a legitamit claim that this version of the petstore was really written by A) a monkey, or B) a MS fundee.
Karma Clown
Oracle did a study showing the reverse with their app server and database.
e t_ bench.pdf
.Net
http://otn.oracle.com/tech/java/oc4j/pdf/9ias_n
In Oracle's study, they achieved results that were as much as 22x faster than
It's not about loving Linux. It's about loving Freedom (TM).
.NET is trifling at best, to say the least.
Realistically, though, we're talking about internet application development platforms here, not basic human rights. Being all high and mighty about not uing
Now of course the 14000 lines in the .Net application...
.NET solution only had 2096 lines, while the J2EE one had 14,000+ lines of code...
:p
I'm extremely curious, as many people have mis-quoted this figure. Where did you get this information? Is there another article that quotes this incorrectly?
The
So much for Microsoft's write tons of shit code and hope for the best mentality
NGWave - Fast Sound Editor for Windows
Lines of code has everything to do with ease of programmer replacment, maintenance costs, and flexibility.
This is about being able to replace your programmers easily if one of them is a pompous ass, being able to move the code base around and adapt it quickly if your OS provider is a pompous ass, and being able to keep maintenance costs down because the overal structure is smaller.
Bullshit. Organization, design and documentation of code has everything to do with ease of programmer replacement, maintenance costs, and flexibility. It's about quality, not quantity. I can have 50,000 lines of code that are split into well concieved, well documented modules that conform to accepted standards. A new programmer can come on board and maintain this code easily. I can have 3000 lines of crap code that they guy who wrote it can't maintain a year later.
Here's the basic story.
Once upon a time, Sun wrote a sample application, called PetStore, as a demonstration of various capabilities of the J2EE platform, and various techniques that might be helpful when writing J2EE applications. As such, it was deliberately over-engineered. A tiny shopping site doesn't need all the techniques they threw at it, it was just a context in which to deliver examples of coding pratices that might be useful in other situations. It was example code.
Speed wasn't a goal. Keeping the LOC low was counter-productive to an application which is basically an example of different coding techniques.
Microsoft saw this, and realised they had a cheap marketing opportunity. By rewriting the Pet Store in .NET, with completely different goals (speed and low LOC), they could score points just by issuing press releases. It's the marketing equivalent of saying "Hey! Our car is smaller and faster than your truck!" It's true, but meaningless.
No matter that it was an apples to oranges comparison. No matter that the Pet Store could be rewritten in Java using Open Source frameworks with about the same number of LOC by one guy in his spare time. This is marketing, not reality.
Charles Miller
The more I learn about the Internet, the more amazed I am that it works at all.