Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ruby On Rails Showdown with Java Spring/Hibernate

Hemos posted more than 9 years ago | from the battle-of-the-overhead dept.

Programming 555

Paradox writes "Java developer Justin Gehtland recently tried re-implementing one of his web applications in Ruby on Rails instead of his normal Java Spring/Hibernate setup. His analysis of overall performance and application size was startling, to say the least. The Java app's configuration alone was nearly the size of the entire Rails codebase, and Rails application was significantly (15%-30%) faster! At the same time, the Ruby community is abuzz because Ruby is getting a new optimized bytecode compiler for its upcoming 2.0 release. Will Ruby on Rails become even faster as a result?"

cancel ×

555 comments

Sorry! There are no comments related to the filter you selected.

Faster? (5, Funny)

Cruithne (658153) | more than 9 years ago | (#12134109)

...Ruby is getting a new optimized bytecode compiler for its upcoming 2.0 release. Will Ruby on Rails become even faster as a result?

I would assume so, doesn't optimized usually mean faster?

Re:Faster? (5, Insightful)

Anonymous Coward | more than 9 years ago | (#12134138)

theres a difference between compiling faster and running faster. If the "optimized" compiler merely spits out the same bytecode at a faster rate, applications will start faster and any JIT compilation done will be faster, but a continuously running application will eventually operate at the same speed as before. If it spits out "better" bytecode, then we'll see speed increases.

Obligatory (5, Funny)

Anonymous Coward | more than 9 years ago | (#12134142)

doesn't optimized usually mean faster?

I'd give you an answer, but I haven't been able to fully test out my optimized Gentoo box yet -- it's still compiling.

Re:Faster? (4, Insightful)

sporty (27564) | more than 9 years ago | (#12134151)

Optimized means that it's doing something better. Smaller binaries? Less memory when running? Faster execution? Faster to compile? In the context of the article, you can assume it's about speed. But out of context, you cannot.

Re:Faster? (4, Insightful)

rbarreira (836272) | more than 9 years ago | (#12134182)

Yeah, an optimized compiler isn't the same thing as an optimizing compiler...

Re:Faster? (1)

Hard_Code (49548) | more than 9 years ago | (#12134272)

Unless the adjective optimized applied to the noun bytecode and not compiler...

Re:Faster? (5, Informative)

ajs (35943) | more than 9 years ago | (#12134241)

When we say "optimized bytecode compiler" these days, we generally mean that it does JIT. I know, I know, it's bad use of the terminology, but generally that's what people mean.

Ruby has one other massive advantage over Java on the medium-term horizon: Parrot. The Ruby-on-Parrot effort is progressing nicely, and when that is complete, Ponie [poniecode.org] will give Ruby transparent access to all of CPAN (thought yet another JITted bytecode system) even for those who don't like or can't use Perl.

At that point, Ruby becomes (IMHO) the most attractive HLL in existance (until Perl 6 lands... IF Perl 6 lands...)

Re:Faster? (1)

sporty (27564) | more than 9 years ago | (#12134273)

Yeah, but even in JIT, is it reducing the memory foot print? Recompiling code ala hotspot did in the JVM at some point? Optimized is still a throw-around word.

Re:Faster? (1)

Karma Sucks (127136) | more than 9 years ago | (#12134500)

I call bullshit.

I've been following Ruby for a while and practically no-one in the community has any interest in Parrot let alone CPAN.

Most of the excitement and focus is on the new Ruby VM Rite as OP mentioned.

Not a safe or true assumption (3, Insightful)

Pac (9516) | more than 9 years ago | (#12134179)

It all depends on what you are optimizing for - you can optimize for size, for instance (smaller but slower applications). You can optimize for portability and end up with code that is both slower and larger (but more portable). You can optimize for almost anything you need. Speed is one factor only.

Anyway, in this particular case you may be right.

how fast can Ruby on Rails go!? (0)

Anonymous Coward | more than 9 years ago | (#12134111)

GO RUBY GO!

Oz (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#12134113)

when can we get Ruby Slippers?

ROR? (0, Flamebait)

Anonymous Coward | more than 9 years ago | (#12134128)

ROR bites. Try zope [zope.org] instead.

Java Problems on my Mac... (-1, Flamebait)

Anonymous Coward | more than 9 years ago | (#12134136)

I don't want to start a holy war here, but what is the deal with you Mac fanatics? I've been sitting here at my freelance gig in front of a Mac (a G5 Dual 2.5Ghz Machine w/ 1 GIG of RAM) for about 20 minutes now while it attempts to copy a 17 Meg file from one folder on the hard drive to another folder. 20 minutes. At home, on my Pentium Pro 200 running NT 4, which by all standards should be a lot slower than this Mac, the same operation would take about 2 minutes. If that.

In addition, during this file transfer, Safari will not work. And everything else has ground to a halt. Even SimpleText is straining to keep up as I type this.

I won't bore you with the laundry list of other problems that I've encountered while working on various Macs, but suffice it to say there have been many, not the least of which is I've never seen a Mac that has run faster than its Wintel counterpart, despite the Macs' faster chip architecture. My 486/66 with 8 megs of ram runs faster than this 2.5 Ghz Dual machine at times. From a productivity standpoint, I don't get how people can claim that the Macintosh is a superior machine.

Mac addicts, flame me if you'd like, but I'd rather hear some intelligent reasons why anyone would choose to use a Mac over other faster, cheaper, more stable systems.

Re:Java Problems on my Mac... (-1, Troll)

Anonymous Coward | more than 9 years ago | (#12134253)

Mac addicts, flame me if you'd like, but I'd rather hear some intelligent reasons why anyone would choose to use a Mac over other faster, cheaper, more stable systems.

Human desire to join cults. I myself considered joining the mac cult and overpay for mp3 players and computers .. but instead I'm kind of thinking of joining a moon cult.

Re:Java Problems on my Mac... (0)

Anonymous Coward | more than 9 years ago | (#12134372)

I see the masters are still at work. bravo.

Re:Java Problems on my Mac... (0)

Anonymous Coward | more than 9 years ago | (#12134412)

1) How is that a Java problem?

2) I've run OS X since the first Public Beta and never had that type of issue on a lot slower of machine. Even my new Powerbook does not have that issue. Sure nothing else is bringing your computer to a halt?

Here we go again (2, Insightful)

pj-allmod (822913) | more than 9 years ago | (#12134143)

Nothing like fanning the flames of an already hot topic between J2EE & RoR developers. Just watch, it's impossible to have an intelligent discussion between the two groups.

Re:Here we go again (5, Funny)

Anonymous Coward | more than 9 years ago | (#12134167)

Just watch, it's impossible to have an intelligent discussion between the two groups.

Is that so, Mr. Poopyhead?

Re:Here we go again (1, Offtopic)

I confirm I'm not a (720413) | more than 9 years ago | (#12134335)

Nothing like fanning the flames of an already hot topic between J2EE & RoR developers.

Oh, I don't know! On the pro-Java forum theserverside.com [theserverside.com] , where this article has already been covered, they're pretty open to the Ruby-on-Rails [theserverside.com] community...

(Warning: you may want to wait 361 days - crap April Fools ahead)

Re:Here we go again (4, Interesting)

TrekCycling (468080) | more than 9 years ago | (#12134434)

Are you serious? I would argue that if there is such a thing as a J2EE "fanboy" (to use a gaming term) then that is an individual who cares only about job security and not about being a good technologist. I'm a developer with 10 years of experience. My experience is in everything from ASP with VB/JScript to PHP to Java. I use whatever the company deems best at the time or whatever I feel is the best solution at the time. I think there is a virtue in being agile and being able to pick up new technologies. The downside is that you don't go as deep. So I don't have 5 years of J2EE on my resume. The upside is that I'm not a J2EE fanboy and if next week my company decides that Ruby is the way to go then I pick up a Ruby book, start poking through the documentation and learn Ruby.

I think J2EE "fanboys" are either too lazy to learn something new, too philosophically rigid to allow for the possibility that there are other ways to accomplish the task at hand or don't, or they're worried that RoR becoming popular would invalidate their 5 years of J2EE experience.

I know people that probably fit this bill in some manner. I would hope for their sake and the sake of their organizations, however, that they'd be willing to pragmatically look at the problem being presented and make a decision based on what's best for the organization, be it Java or Ruby. At the end of the day I believe being a good technologist and a good communicator, being eager to learn and willing to try new things is more valuable than just being a Java wonk. Flexibility is a virtue. I imagine most Java developers are more flexible than you give them credit for. Although I know there are exceptions.

C is still the King !!! (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#12134144)

check it out [debian.org]

Everything is else just plain slow.

BIG SUPRISE ORM SLOWER THAN SQL DATABASES (-1, Troll)

Anonymous Coward | more than 9 years ago | (#12134147)

Move along... nothing to see here...

any comparison like this... (1, Insightful)

fedork (186985) | more than 9 years ago | (#12134156)

...

without reading TFA, any comparison of this sort does not have much value. Maybe if he reimplemented his app using same Java he would get 50% speed and codebase improvement? Maybe the original was just too poorly coded /overengineered / whatever? Ruby on Rails MAY be much better but any evidence like this is hardly valuable, that's why I would not even bother to RTFA

Re:any comparison like this... (1)

RazzleFrog (537054) | more than 9 years ago | (#12134210)

Well if the original was poorly coded or overengineered it may speak to the adequacy of the development platform. It may be that RoR is just an easier platform to develop well written applications.

Re:any comparison like this... (1)

fedork (186985) | more than 9 years ago | (#12134373)

no doubt it might, the point is that the example in the article is pretty meaningless/ does not prove anything...

Re:any comparison like this... (0)

Anonymous Coward | more than 9 years ago | (#12134445)

You say over engineered, I say the right tool for the job, or at least some jobs. I'm familiar with ROR and the Spring/Hibernate solutions. ROR looks best suited to quick, simple database driven websites. On the other hand, Spring/Hibernate is targeted at larger scale web applications. Would you trust ROR to handle your banking transactions? I wouldn't. I'd be more likely to trust Spring/Hibernate, seeing that Hibernate is the primary implementation of the future j2ee ejb 3.0 spec.

Re:any comparison like this... (1)

rbarreira (836272) | more than 9 years ago | (#12134215)

Yeah, this comparison on slashdot's page makes it seem like a really intelligent site... "Look, some random guy who maybe knows how to program well with java thinks it's slower than Ruby!"

Give us a break...

Re:any comparison like this... (1, Insightful)

OwnedByTwoCats (124103) | more than 9 years ago | (#12134265)

I can't read TFA; slashdot effect?

Reimplementing any app, changing the language or no, results in a better implementation, because the (re)implementor has a better understanding of the problem.

If he were to go back and redo the Java app in Java, it would be interesting to learn how it turned out.

Re:any comparison like this... (3, Interesting)

killjoe (766577) | more than 9 years ago | (#12134297)

I think the crux of the matter is that he was not taking advantage of some of what these java containers offer. Things like queues, soap, RMI, CORBA bindings, remote invocations etc.

The lesson here I think is that unless you plan on running on multiple containers and using asyncronous calls java is overkill.

If you do need those things then ROR won't work at all.

Another thing is that ROR wants you to design the database from scratch to fit it's naming rules. It's not really designed to work with existing databases. For example it can't map the ugly database field names into nice attribute names for your objects. To me that's a pretty big shortcoming.

Horses for courses (3, Interesting)

16K Ram Pack (690082) | more than 9 years ago | (#12134368)

From what I've seen so far (trying it out), RoR has its place.

It's a little bit like using something like MS Access. If you play along with MS Access, and don't try and do things that it doesn't do particularly well, then you can actually build desktop database systems very quickly. If you try and go outside of the "Access way", it becomes a quagmire.

There are tens of thousands of sites out there that don't need to have queues, SOAP, RMI etc. They might be someone's list of restaurant reviews or something. Maybe RoR has a good place for that.

Re:any comparison like this... (4, Insightful)

LnxAddct (679316) | more than 9 years ago | (#12134325)

In addition to that, how well does the ruby implementation scale? My understanding is that a good J2EE implementation is capable of scaling to thousands of clients (one article I read claimed a 250,000 client load), the ruby implementation might start crawling after as little as 50 clients. Turning up a page 125ms faster is more or less meaningless when you can't reach most of your potential customers, and more importantly, after a few start visiting it gets slower and slower. So I'm curious to see what kind of extensive laod testing he did for both implementations. Other important things to consider are how complex his needs are compared to an enterprise and how extensible both implementations are. How exactly did this Joe Schmoe get on the front page of slashdot?
Regards,
Steve

Re:any comparison like this... (2, Insightful)

swimmar132 (302744) | more than 9 years ago | (#12134491)

With fastcgi and a decently tuned server, I've heard people getting 1000 req's per second. And lighttpd doesn't take up much memory. And you can always add more applications servers if that's not fast enough.

Re:any comparison like this... (5, Insightful)

Paradox (13555) | more than 9 years ago | (#12134340)

Justin is a respected and skilled Java developer who's got a Developer's Notebook for Spring set to hit the shelves any day now.

The app he wrote was quite complicated, and he freely admits that Rails got some free jump-starting because of his understanding of the domain. But you're going too far in saying he'd get a 50% speedup from a rewrite. His Java codebase needs work, but not that much work.

He observed that the more complex the action, the faster RoR ran compared to Java. This is very counter-intuitive, so he went into an explanation of why.

Re:any comparison like this... (2, Funny)

Minute Work (749085) | more than 9 years ago | (#12134354)

...without reading TFA, any comment of this sort does not have much value. Maybe if he re-read the article his comment would get a %50 improvement? Maybe his original thoughts were poorly conceived/whatever? This comment MAY be insightful but any comment like this is hardly valuable, that's why I would not even bother to RTFP

Re:any comparison like this... (1)

northcat (827059) | more than 9 years ago | (#12134423)

You post looks like a poor attempt at saying "no way, java still rules."

Re:any comparison like this... (1)

TrekCycling (468080) | more than 9 years ago | (#12134454)

Me thinks someone is a J2EE developer who doesn't want to have to learn something new down the road. :-)

a record? (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#12134160)

Could this be a record for the quickest slashdotting in history?

Not fast enough for Slashdot... (4, Funny)

ChrisKnight (16039) | more than 9 years ago | (#12134172)

Fifteen to thirty percent faster, and still crushed under the load of Slashdot.

Re:Not fast enough for Slashdot... (1)

zorander (85178) | more than 9 years ago | (#12134300)

It just loaded in 500ms for me on my crappy wireless connection--what are you talking about?

Nah (0)

Anonymous Coward | more than 9 years ago | (#12134178)

"Ruby is getting a new optimized bytecode compiler for its upcoming 2.0 release. Will Ruby on Rails become even faster as a result?"

Nah, that couldn't happend, could it???

Ruby on rails performance (2, Funny)

Anonymous Coward | more than 9 years ago | (#12134186)


Beating Java's performance and garrulous xml-based configuration is like shooting dead fish in a barrel.

Re:Ruby on rails performance (2, Funny)

adavidm (642259) | more than 9 years ago | (#12134393)

....with an elephant gun

Security (0, Flamebait)

duffbeer703 (177751) | more than 9 years ago | (#12134201)

I recall one of the rather trivial Ruby on Rails tutorials having a remote code execution exploit.

RoR is a cool concept, but definately not ready for any kind of real deployment.

Re:Security (0)

Anonymous Coward | more than 9 years ago | (#12134416)

Thank you for this completely worthless comment.

Do you have a link to back up this claim? Or did you hear it from a friend of a friend of a friend?

And how does having a remote code execution exploit in some tutorial somewhere make RoR not ready for real deployment? I'm sure I could come up with a trivial remote code execution exploit with C, but I've heard that some enterprises deploy their software using that!

Re:Security (0)

Anonymous Coward | more than 9 years ago | (#12134450)

Bullshit.

Re:Security (3, Informative)

Tobias Luetke (707936) | more than 9 years ago | (#12134472)

Nice FUD... Except that its made up. Rails is very secure by default (uses pepared statements and things like this).

It does whatever it can do to make the framework part of the application secure and even offers a book on security on the hieraki bookshelf for the user side of things: Securing your Rails application [rubyonrails.com] .

This is a great example of rails quality documentation. have a look at the bookshelf itself: Hieraki bookshelf [rubyonrails.com]

And the application which powers it is open source (MIT) at www.hieraki.org [hieraki.org]

This is a flawed recollection. (5, Informative)

Paradox (13555) | more than 9 years ago | (#12134484)

There was a brief example of this on ONE of the wiki-based tutorials in which the person posting the tutorial didn't use Rails's built in SQL search features or safety features. Because of this, there was an SQL injection hole. It was promptly corrected.

No amount of safety can make up for novice mistakes. Rails provides everything you need to make secure webapps, and it lets you do it painlessly.

Re:Security (5, Insightful)

Xugumad (39311) | more than 9 years ago | (#12134495)

Dear Moderators,

THIS IS NOT INFORMATIVE. It is INTERESTING. If the poster had supplied supporting evidence at all, it would have been a start towards informative.

As it is:

1. Which tutorial was it?
2. Was the problem a fundamental problem with Ruby on Rails, or the tutorial itself.
3. If it was a problem with Ruby on Rails, can it be fixed?

Re:Security (1)

CatGrep (707480) | more than 9 years ago | (#12134510)

RoR is a cool concept, but definately not ready for any kind of real deployment.

Here, Here! And since the earth is flat we can't have crazy people going out and sailing off the edge of it because they think it might be spherical.

Development Resources? (3, Insightful)

Pants75 (708191) | more than 9 years ago | (#12134202)

Code base size and speed aside.

How much time did it take to develop the site compared to Java?

I ask here because the site is dead, Ruby isn't a magic hammer after all.

Pete

Re:Development Resources? (1)

pj-allmod (822913) | more than 9 years ago | (#12134235)

In my experience, you can develop applications much faster using RoR. I had an app written in PHP that took me close to two months to write and I had it rewritten in RoR in a little over a week. It's easier the second time around, but I didn't even know how to program in Ruby before using Rails.

Re:Development Resources? (3, Informative)

Paradox (13555) | more than 9 years ago | (#12134247)

The blog is not a ruby-on-rails application.

You are all wrong (5, Insightful)

Anonymous Coward | more than 9 years ago | (#12134205)

There have been many posts concerning the speed of each and every possible language. Some have gone as far as to link to several studies with nice charts and graphs to conclude that X language is faster or X1 is truly the fastest. You are all wrong.

A laguage, in of itself, cannot be measured by speed. A language is merely a group lexical elements with a particular syntax. That syntax has an associated semantics to it. That is it! It is pointless to compare languages purely on speed.

Now, what we can compare is the implementation of a particular language. For example, we can compare the speed differences between the intel compiler and gcc for the same piece of C code. We might find that in most cases, gcc is slower that the intel compiler. Does this mean that C is slow? No! Now, take the same algorithm and port it to Java. Lets imagine that the Java version was 10x faster. Does this mean Java is inherently faster langauge? NO! It means that the compiler, JIT, and HotSpot implementations are better at tranlating Java source code down to the machine level.

So, in summary, a language by itself should NOT be measure in speed. It should be measured by the following:

Maintainability
Ease of Use
Learning Curve
Clear Semantics
Support
Documentation
Standard APIs

Most often, when languages are compared, you are merely comparing the differences in constants in a language! Lets say we implement the Quick Sort Algorithm in C++ and Python. We will probably find that the C++ version is slightly faster. What does this mean? It means the the implementation of C++ generates fewer constants that the Python Implementation. So, the Python version may be slower, but it is only in constant O(1) differences and in most cases this does not matter! Eliminating extra constants ( in any language ) is stupid when you have chosen the wrong algorithm in the first place! ( such as an order n^3 when it could have been n*log(n) ).

So, what is the moral of this story? Pick the right langauge for the right job. It you are doing advanced GUI development and prototyping, C++ is probably not the way to go ( since it is harder to write fast and correctly ). However, it you are doing low-level real-time I/O where constants do matter, then C/ASM is probably the way to go. After you have chosen he right language for your task, you must choose the right algorithm! Algorithms are the key! Algorithms are the only true way to measure the efficiency on any program in terms of memory and speed.

I couldn't agree more (4, Informative)

Weaselmancer (533834) | more than 9 years ago | (#12134292)

Language is merely description, implementation is what you can benchmark.

And I also have to say, what we've got here is the single most intelligent AC post in the entire history of Slashdot.

Re:You are all wrong (1)

Hard_Code (49548) | more than 9 years ago | (#12134327)

And languages are not incapable of specifying requirements that result in implementations which perform the same taks more slowly than other languages. That shouldn't be hard to understand.

Re:You are all wrong (4, Insightful)

lbmouse (473316) | more than 9 years ago | (#12134329)

Add one more to your list: General Acceptance.

If you're the only one using a language, it can get pretty lonely. Plus, managers like technology that is generally popular in case you get hit by a bus.

No need to be pedantic (4, Informative)

jfengel (409917) | more than 9 years ago | (#12134330)

This is all true, but as software developers we tend to use the word "language" loosely to mean, "The syntax, the compiler, the libraries, and the execution environment." So while a language can't be inherently faster than another, some languages have highly efficient, readily available implementations, and others don't.

That's a matter only of constant speedup, assuming that the implementation is competent, and therefore theoretically swamped by the complexity of the algorithm. But if you've implemented the same algorithm using both systems, a constant speedup of 10 is an order-of-magnitude speed improvement. Even with the really, really fast computers we use today that makes a difference to a lot of applications. (And I've used plenty of languages where could get a 10x improvement by switching to a better language.)

In this case there isn't even a single Java environment; there are numerous JVMs out there and I hope they tested several of them before writing the article. (I doubt it, but that's a whole different story.) You're probably not going to get a 10x difference, but 2x wouldn't be uncommon for certain applications.

So you're using the terminology correctly and everybody else is using it wrong. They should talk about the "Java system" or "Java environment" rather than Java language. But I think nearly everybody reading the article knew what was meant.

Re:You are all wrong (5, Insightful)

ajs (35943) | more than 9 years ago | (#12134363)

"A laguage, in of itself, cannot be measured by speed."

Not so.

There are purely functional languages that are -- for all practical purposes -- impossible to optimize as well as either procedural or hybrid procedural/functional languages.

However, that's beside the point. Java in particular is NOT just a language. Java is a specification for a fair amount of the IMPLEMENTATION as well. Java specifies the behavior of GC, type storage, and many other implementation details ot a level that precludes many hardware or OS specific optimizations.

There are non-conforming compilers that ignore these strictures (and get excellent performance), but they are not -- strictly speaking -- compiling Java.

Languages like Ruby, Python, Perl and PHP on the other hand, make no such strict demands, and thus can be optimized appropriately for the platform.

Re:You are all wrong (1, Insightful)

Anonymous Coward | more than 9 years ago | (#12134468)

Let me know more about those mysterious purely functional languages that can't be optimized.

Oh, and read Boquist 99, I think it covers producing optimized code for lazy functional languages.

Re:You are all wrong (1)

gavri (663286) | more than 9 years ago | (#12134366)

Patrick Peak (co-author of Hibernate Quickly) has made a comparision [theserverside.com] of Hibernate and Active Revord based on factors other than performance. Very informative.

Re:You are all wrong (1, Interesting)

Anonymous Coward | more than 9 years ago | (#12134374)

Right, except that this is all nonsense. For instance, due directly to Python's nature, Python will always be slow. Python HAS to do a lookup for variable names. This will always be slow.

Java is slow. How much of this is due to the nature of the language, and how much due to its implementation? I dunno, I really don't know much about Java. I do know that every interactive Java program I have ever used has been hilariously, stupidly, ridiculously slow. Practically speaking, the point is, right now, if performance is a significant issue, Java is not the right choice.

I disagree with this nonsense about "C++ is not the way to go." C is almost never the right choice. Most of the people currently writing C would be better off with a much higher level language (whether it be Python, Ruby, Lisp, whatever), and the rest would be better off with C++. Exactly what do you gain by using C rather than C++? Nothing. C has NO benefits over C++.

(In case it wasn't clear, I do agree that performance often isn't the issue that people think it is.)

Re:You are all wrong (1)

DrXym (126579) | more than 9 years ago | (#12134447)

And most server side code spends its life serving requests and talking to back end business objects / databases. This means there is a lot of built-in latency with most of the code sitting around waiting for something to happen.


That's the reason in the first place for Java to be attractive. It doesn't have to be as fast as C++. What's more important is that it doesn't crash, has an extremely powerful set of APIs for doing all kinds of enterprisey things and runs just about everywhere.


There's no doubt either that you could do the same in Perl, Python or Ruby but speed is generally the least of your issues. I'd rather have code that is readable and that it has the tools for the job it is doing. If it works already in Java I see zero gain in moving it to another language, especially as Java already has fantastically good web serving functionality with numerous commercial and non-commercial standards implementations to choose from.

Re:You are all wrong (1, Interesting)

Anonymous Coward | more than 9 years ago | (#12134459)

Now, what we can compare is the implementation of a particular language

Well, I think it's pretty obvious that we're talking about the Ruby on Rails implementation of Ruby and Sun's implementation of Java here, so in effect we are comparing implementations, not the languages themselves. That's just the way programmers talk about stuff and most are easily able to make that connection without requiring explanation.

What you said is absolutely correct and I totally agree, but it's not really applicable in this situation.

Re:You are all wrong (1)

Bellyflop (681305) | more than 9 years ago | (#12134474)

Most often, when languages are compared, you are merely comparing the differences in constants in a language! Lets say we implement the Quick Sort Algorithm in C++ and Python. We will probably find that the C++ version is slightly faster. What does this mean? It means the the implementation of C++ generates fewer constants that the Python Implementation. So, the Python version may be slower, but it is only in constant O(1) differences and in most cases this does not matter! Eliminating extra constants ( in any language ) is stupid when you have chosen the wrong algorithm in the first place! ( such as an order n^3 when it could have been n*log(n) ). While I don't disagree with your assertion that people ought to pick the right language for the job, there are many situations where a constant time increase isn't acceptable. Web programming generally isn't one of them, but consider the world of scientific and financial calculation. In those situations, any time increase can be very detrimental.

Wait..... (-1, Troll)

Landak (798221) | more than 9 years ago | (#12134209)

So, the point of this study is to show that Java is inefficient?

AHAhahahahahaahahacough *spluter*, er, *Ahem*, any decent programmer would tell you that while not having to memory manage is a blessing, the VM doesn't exactly make a textbook job of it. Specifically, well, opening Azerues on this mac sacrifices about a quarter of my ram to Java alone (I have a gig).

I don't mean to troll, but what is the point of having java as a dynamic deployment platform. All you need is pico and "PHP, perl, and MySQL for dummies" ;-P, much more efficient, and also quite a lot less messy.

I think the reason why I don't admin a huge corporate dynamic website is about to be pointed out though.....

Re:Wait..... (0)

Anonymous Coward | more than 9 years ago | (#12134309)

Well, the thing about Ruby vs. Java is that Ruby is a general purpose programming language (unlike PHP).

Re:Wait..... (0)

Anonymous Coward | more than 9 years ago | (#12134324)

So, the point of this study is to show that Java is inefficient?

Yes. A Java developer intentionally set out to show that his preferred language was inefficient.

I don't mean to troll

Are you sure about that? You don't seem to have read the Slashdot summary, let alone TFA.

Re:Wait..... (1)

Bellyflop (681305) | more than 9 years ago | (#12134389)

When was the last time that you used and evaluated Java?

Re:Wait..... (1)

LnxAddct (679316) | more than 9 years ago | (#12134406)

Thats all well and good until your clients reach 4 digits, maybe even 3 digits. Java is also quite fast and makes an excellent server platform. It is constantly optimizing its own code on the fly, how cool is that? It is also purposely verbose as it makes large projects involving many members in different teams easier. Comments are sure nice, but in the end the code does the talking. So many ignorant people that have never been involved in enterprise really need to read up.
Regards,
Steve

Re:Wait..... (3, Insightful)

markv242 (622209) | more than 9 years ago | (#12134453)

I think the reason why I don't admin a huge corporate dynamic website is about to be pointed out though.....
Well, if you insist...

Java as a "dynamic deployment platform", as you put it, offers trivial matters such as load balancing, server-independent sessions, and hot deployment (where new sessions get the new codebase, while old sessions get the old codebase), just to name a few. These three items alone are nearly impossible to pull off in a PHP/MySQL configuration, without keeping your sessions in a database and reloading them for every single pageview. Nearly every Java app server gives you these without having to write any code.

And I think that's where a lot of these pseudo-flamewars get started. On an individual page basis where all I'm doing is "SELECT * FROM NEWS WHERE ID = ?", on one machine, of course PHP and MySQL are going to run faster. But once you start deploying your application to multiple boxes, the advantages of Java become clear.

Additionally, I would challenge you to this test: let's say you have a stock PHP installation, without the GD libraries linked into the PHP binary. Now let's say you want to create a PHP application that uses GD. Do you A) recompile your PHP server, or B) give up platform-independence and run some kind of system call? Under Java, the answer is C) add in a GD jarfile to your application, and you're done, without any recompilation or configuration on your part.

My point, and I do have one, is this: in exchange for the inefficient startup time of the VM and potentially inefficient bytecode (depending on your app server-- Tomcat is a real dog in this aspect) Java gives you a ton of freedom. With hardware getting faster every day, I'll make that tradeoff every single time.

Re:Wait..... (1)

Landak (798221) | more than 9 years ago | (#12134507)

Ahh, okay. That makes a lot more sense. However, what about clustering your boxen, *then* running all your company's IT needs from it; thereby eliminating issues such as that? Couldn't you make damn sure everything you were using, and were likely to use, ran on that "One machine", then optimise it through the teeth to allow you to do more?

Though I do really see where you're coming from.

Re:Wait..... (1)

TrekCycling (468080) | more than 9 years ago | (#12134503)

Actually what you just pointed out is that you won't or *can't* "admin a huge corporate dynamic website". A good technologist could make RoR or Java work just as well as your "stack" of Pico, PHP and MySQL (which, as we all know is inherintly easier to maintain than a Java app).

Article Text (5, Informative)

Anonymous Coward | more than 9 years ago | (#12134211)

Article text in full, copied directly from Justin's blog:

So, a few weeks ago I made an offhanded post here about my new-found love for Rails. I'd been skipping off the surface of Ruby for a while, trying to decide if it, or Python, or Groovy, or something else, ought to fill out the empty slot in my tool belt. (I'll save the "why LISP isn't on this list" post for another time.) Rails seemed like an excellent way to put Ruby through a workout, and I had the right sized project to try it out with.

The project itself is not open-source; the client is now and shall remain anonymous. But they are paying me my going rate to do this work, which makes it a commercial Rails project, and it will in the future be installed into some rather large organizations. I can't really say much about what the application's domain is, but I can lay out the general principles of the app.

The application must support multiple users, in the order of 10-100 concurrently. The load isn't particularly high, but the application will be treated like a desktop app (more specifically, a spreadsheet replacement) so it has to be responsive. The application is for managing pieces of a large machine process. There are lots of types of components to be managed, and the relationships between them can be quite complicated. There are no one-to-one relationships in the model, but plenty of one-to-many and many-to-many. In addition to managing the components, the application has to allow for the addition of entirely new categories of components as well as a variety of customizable fields. Finally, the authorization rules call for a breadth of user roles with a complex mapping of permissions to those roles.

I've finally gotten around to running the profiling numbers and doing some comparison between the two systems. I won't spoil the suspense by listing my conclusions up front -- you'll have to scroll through the rest of the post to see them. But, first, let me set the stage: the original application is based on the Java/JSTL/Spring/Hibernate/MySQL stack. I used ACEGI for the security, SpringMVC for the web controller, and was using Hibernate 2.x for the O/RM. To increase performance, I was using the default output caching from SpringMVC and data caching in Hibernate. The re-implementation is in Rails on top of MySQL. The authorization is done through a custom observer and a custom authorization class, which uses a declarative rules file for permission mapping. For performance, I'm using a combination of page caching, action caching, and cache sweepers (observers whose job it is to expire cached pages).

Now, for the comparisons:

Time to Implement
I made a comment about this in the previous posts on the topic, and that comment has been quoted widely out in the wide blogosphere as a classic example of Rails hype. So, let me make it plain: any time you re-write an application, it will go almost infinitely faster because you already have a firm grasp on the problem domain. Such was the case for me in my re-write; we'd spent so much time on the domain model and the database schema that the second time through the application, everything already made perfect sense to me. Any comparison of how long it took to implement one or the other is bogus, since the only fair comparison would be to implement two roughly functionally equivalent projects in the two different stacks and measure the competitive results. Since I have not done that, making statements about how it only took 5 days to re-implement the site are almost meaningless. What I can say is that I had more fun implementing it the second time, but that's just personal preference.

Lines of Code
This one is a lot more interesting. Folks will tell you all the time that there is a running debate about the meaningfulness of LOC comparisons. They're right; there is a running debate. I just think it's moot. For my money, the fewer lines of code I have to write to get a piece of functionality, *as long as those lines are clear in meaning*, the better off I am. Obfuscated Perl programs don't make the grade; I can write some really concise Perl code and not have any idea, three months later, what the heck I was doing. But if the code is legible, its intent obvious, then more concise is better, pure and simple.

Bear in mind that this comparison is somewhat unfair. The Rails version of the app has been in development for an extra month (meaning a month's worth of new features added) while the Java version has been stagnant since the switch. Since the Rails version started out as an experiment, I don't have a clear history of the codebase to be able to produce a version that is identical in features to the Java version. Therefore, I've made the comparison based on the current state of the app vs. the abandoned Java version.

The LOC counts used here do not include comments or unit tests, nor do they include simple punctuation lines (lines with just a "}" or "end").

Without further ado:

Lines of Code
Rails: 1164
Java: 3293

Number of Classes:
Rails: 55
Java: 62

Number of Methods:
Rails: 126
Java: 549

Configuration Lines
Rails: 113
Java: 1161

Those numbers are beyond striking. The configuration count alone is enough to make me think long and hard about what I've been doing lately. Let me forestall any criticism about my "agenda", by the way. Somebody recently said that I must have an "anti-Java" or an "anti-Spring" agenda. That is far from the truth, since my Spring: A Developer's Notebook hits shelves any day now. I don't want people to stop using Spring, or Java. In fact, I want lots and lots of Java developers to use Spring and lots and lots of non-Java developers to start using Java so they can start using Spring. But one of the things I like most about Spring (its concise configuration) is still, well, huge, compared to the same app in Rails.

Performance
This is where everybody really wants to see the numbers. So, for the sake of total specificity, the following numbers were generated on a 1.5GhZ Mac OSX (10.3.7) PowerBook with a 4200rpm hard drive and 1GB of RAM. The Java app is running on Jakarta Tomcat v 5.0.28, while the Rails app is running in Lighttp with FastCGI. The setups are standard for each application stack.

Since both stacks have different caching mechanisms, with different degrees of difficulty to manage them, I'll start the performance comparison with a walk through the application without using the caching systems. To generate the first number, I walked through every screen in the application (using the screens available in the Java version to form a subset of the screens available in the newer Rails version) hitting pages that have not been cached yet. This starts from logging in, then hitting every available piece of functionality once. These numbers do not include the time it took me (the user) to navigate to the next request, only the time to process the requests. Both applications had roughly equivalent logging turned on (obviously, it can't be exact, but without the logging, I couldn't provide measurements). Here's what I found out.

To walk the entire application feature set, once, in Rails, without caching, took 41.801s. To walk the exact same feature set in the Java app took 58.369s. These numbers are averages over five attempts with each app, with full restart between to give the cleanest runs possible. Those summary numbers are deceiving, though. What I found was that, the less complex the feature, the faster the Java app served it relative to the Rails app. The more complex the feature, the slower the Java app served it relative to the Rails app. Some of that difference might be changes to the model during the re-implementation based on a better understanding of the domain. Regardless, that difference comes out to show the Rails app at ~30% faster than the Java version when caching isn't taken into account. If I am generous and say that half of the difference is due to optimizations in the model, that still leaves us a 15% better performance in Rails.

The caching story is interesting. The default caching mechanism for Rails is either page caching (caching the output of the rendering to a physical html file and letting the server serve it directly instead of invoking Rails the next time it is requested) or action caching (similar, except the output is cached in memory or another kind of store and Rails is invoked to process the request). On the Java side, there is JSP pre-compilation, Spring output caching and of course Hibernate data caching. I used a simple load tester to test a couple of pieces of functionality in the application. For each URL, I ran the test without a pre-existing cache of the response, then again with it, 100 times each, and then determined the number of requests per second.

Functionality 1: Rails, 100 runs, no pre-existing cache: 75.59 request/second. Rails, 100 runs, pre-existing cache: 1754.39 requests/second. Java, 100 runs, no pre-existing cache: 71.89 requests/second. Java, 100 runs, pre-existing cache: 80.06 requests/second.

Functionality 2: Rails, 100 runs, no pre-existing cache: 62.50 r/s. Rails, 100 runs, pre-existing cache: 1785.15 r/s. Java, 100 runs, no pre-existing cache: 80.06 r/s. Java, 100 runs, pre-existing cache: 88.97 r/s.

These numbers are not a great comparison, because there is tons more I can do to increase the cache performance of the Java application. No doubt whatsoever (I just hadn't gotten around to it by the time I abandoned it). What *is* interesting, though, is that the Rails page caching maxes out . The server can't serve the pages any faster than that. And with the Rails cache_sweeper observer pattern, it is dead-simple to use this hyper-fast caching whenever possible (obviously, highly dynamic pages can't be cached, but that's the case with that kind of page in any application stack). If you switch to the action caching (which allows all the filters to be executed) the Rails app still ends up in the 800-1000 requests/second range.

Conclusions
So what do I think? I think that the application I'm working on is perfectly suited for Rails and Rails is perfectly suited for it. I think that I have had more fun working on the Rails app than the Java version. However, I think that the Java version is just as capable, and could be just as performant, as the Rails app. To me, the eye-opening revelation isn't "Rails is faster than Java/Spring/Hibernate". It's "Rails can be very fast". I think that there is a lot to be said for Rails, and it deserves much of the press it is getting. However, I don't think its a Java-killer. I think there are plenty of applications, and development teams, that are better suited to Java and its immense universe of available support libraries. I certainly am not going to stop developing in and learning about Java just because I've discovered Rails. On the other hand, I am going to spend more of my time trying to find projects that I can use Rails on.

I'm extremely interested in how these numbers strike folks, and whether there are other comparisons that you would find useful. So interested, in fact, that I'm risking blog-spamming by turning comments back on. So, if you have some other comparisons you would find useful, or some insight onto these numbers, or even some things you think I ought to try to make the comparisons better, let me know. I can't promise I'll tackle them all, but I think it will be interesting.

News Flash! (-1, Troll)

Kimos (859729) | more than 9 years ago | (#12134221)

Java is big and slow!

Next breaking story:
Microsoft is insecure!

Re:News Flash! (0)

Anonymous Coward | more than 9 years ago | (#12134290)

Java is big and slow! But would it have survived the slashdotting?

Java compared to Ruby (1)

nitinshantharam (873097) | more than 9 years ago | (#12134240)

So how is java compared to ruby? Is ruby a lot faster or on par with the speed of Java (on most systems)? And how does ruby compare to java at the moment? I wonder if its worth switching over from java to ruby..

Re:Java compared to Ruby (1)

gregarican (694358) | more than 9 years ago | (#12134441)

Since Ruby is an interpreted language and Java is typically JIT compiled I don't think certain studies stating ROR is faster is a totally resounding victory. But in terms of code being concise, readable, totally OO, etc. I choose Ruby hands-down. Just check out a handful of the Ruby tutorials and compare the code with Java. I wouldn't use anything else but Ruby now that I've discovered it and have gotten into it...

Mirror (4, Informative)

blackmonday (607916) | more than 9 years ago | (#12134282)

Mirror Here [mirrordot.org] .

Ruby is a toy (0, Troll)

ahmetaa (519568) | more than 9 years ago | (#12134284)

RoR is a toy comparing to Hibernate and Spring. There is no serious caching, no serious transation capabilities, or messaging mechanisms. hype and buzz. Also, Check this page for a comparison of RoR and Hibernate. However, it is probably better than Php. http://www.theserverside.com/articles/article.tss? l=RailsHibernate [theserverside.com]

Re:Ruby is a toy (5, Informative)

Paradox (13555) | more than 9 years ago | (#12134460)

There is no serious caching
Incorrect. In fact, RoR's caching complete destroys Java's caching in Justin's comparison. You can read about Rails' caching here. [rubyonrails.com]
No serrious transation capabilities
Obvious jokes about your spelling aside, Ruby provides these already. Rails does not need to provide them.
or messaging mechanisms.
This complaint is flawed. However, Rails can accomplish what you're asking for if you want to. It's just that, assuming I understand what you're parroting, it's a very bad idea to do it.
hype and buzz.
Only if you don't bother to find out the truth.

First Post! (5, Funny)

lexbaby (88257) | more than 9 years ago | (#12134305)

First post!

--
Posted Via JFPB - Java First Post Bot

Mod Parent Up! (1)

saintp (595331) | more than 9 years ago | (#12134358)

+1, Embarassingly stupid

Application (4, Insightful)

Tobias Luetke (707936) | more than 9 years ago | (#12134310)

Speed is a stupid mesure for web apps. There is nothing easier to scale then webapps in the world. You can cope with any amount of traffic by just throwing more hardware on the problem in a share nothing environment like php, perl or ruby/rails.

Whats interesting is the development speed and thats what the comparison between the java and the rails version highlighted well. For a great analysis look here: weblog [rubyonrails.com]

What makes the above link so special are the comments from the java community saying that the two examples are not functionally equivalent. This is really golden because they are really not. The rails version ( which is 3 lines of code ) does everything the java code does plus tons and tons of more things just by taking educated guesses after looking at the SQL schema.

Rails is a remarkable framework and a glimps of what programming will be like in the future. Yarv will just save some hardware costs

--
First they ignore you, then they laugh at you, then they fight you, then you win. -- Gandhi

Re:Application (1)

LiquidCoooled (634315) | more than 9 years ago | (#12134369)

Having an application compllete its task 25-30% quicker than before obviously saves you the hassle of throwing extra hardware at the problem.

If the increases you see still aren't enough, then you add more hardware, but faster apps = more value for (hardware) money.

Its stupid to NOT see that.

Re:Application (1, Interesting)

Anonymous Coward | more than 9 years ago | (#12134385)

For a great analysis look here: weblog [rubyonrails.com]

You call that an analysis? You must have serious problems.

And please tell me what the Rails version does more. I'm very interested. The Java version does more imho since it uses ordinals for every entry and keeps them always ordered, the Rails version sets the ordinals to null if the entries are done and relies on the database natural ordering.

Screenshots like this are totally useless since they compare things that can't be compared. Rails handles lists well because it was written for Basecamp that does to-do lists (and more). So of course it's shorter since the functionality has simply been moved to the core framework (Acts -> List).

Ruby Rocks ! (1)

james_in_denver (757233) | more than 9 years ago | (#12134315)

If you haven't used it, you might want to give Ruby [ruby-lang.org] a try.

I was stunned when I used the Ruby on Rails package [rubyonrails.org] and had content driven web-apps up and running in a few hours, without the headache of deployment descriptors and no need to wrap them up in War/Jar/Ear files.

The language and it's syntax are VERY lean and elegant. It's almost as if Ruby is what Java could have been (without the bloat)

And with the GUI, Database, XML, Network, and the rest of the other bindings it is fairly complete runtime environment.

wtf... (0)

Anonymous Coward | more than 9 years ago | (#12134345)

just write it in C if speed and size are issues.

Line counts, method counts.. all lies. (2, Insightful)

ahmetaa (519568) | more than 9 years ago | (#12134362)

Oh please.. Author talks aout line counts and method numbers.. You count getter setter methods? you count the lines for {} symbols and getter-setters? You know that they can be produced lets say in 3 seconds with any modern Java IDE.. it has no meaning what so ever to put them into consideration in terms of productivity.. sigh.

Mojavi (4, Informative)

joelhayhurst (655022) | more than 9 years ago | (#12134379)

Slightly off topic, but thought some might be interested.

There is a pretty cool and full featured MVC framework for PHP called Mojavi [mojavi.org] . If you like PHP and think Ruby on Rails or any other MVC framework is what you're into, you might want to check it out.

Ruby marketing vs Cherrypy (2, Insightful)

alex789 (873201) | more than 9 years ago | (#12134382)

15% - 30% faster! Wow. I hope anyone who ever developed anything for java is reading this so that they can start reimplementing all their code right away.

Another showdown I'd like to read about is that between Rails and Cherrypy [cherrypy.org] . Not in terms of technological superiority, but in terms of marketing skill. Why is the web abuzz with Rails, while Cherrypy is almost unknown.

This isn't flamebait. I'd really want to know how they did it.

Damn stupid summary format (3, Insightful)

Anonymous Coward | more than 9 years ago | (#12134417)

Why do most of the article submitters have to end their summaries with a moronic or otherwise obvious or thought un-provoking question?

Does this mean the code will be faster?

What does the Slashdot community think about that?

Is this the end of free software?

This whole damn site is a discussion site. What does "What do slasdotters think about this?" add? Especially bad is the monthly article on total cost of ownership or the invalidity of the GPL ending with the "Is this end of FOSS?"

Hibernate too hyped (4, Insightful)

Espectr0 (577637) | more than 9 years ago | (#12134419)

Hibernate seems to be the most hyped technology for webapps on java right now. I evaluated it to use it on my thesis.

I don't trust/want something to auto generate my sql tables and such based on my objects. That leads to problems, since the queries can't be tuned or maybe you don't get what you expect.

So, i am using SqlMaps. You put your sql queries in a separate .xml file and use them with very few lines of code. It maps the results of the queries to your javabeans. Really simple, but powerful, there's a whole way of doing dynamic queries (i.e, if some object exists, do something with it, else don't)

Disclaimer: i don't have any relationship with sqlmaps, i am just a happy user.

Re:Hibernate too hyped (1, Insightful)

Anonymous Coward | more than 9 years ago | (#12134483)

Apparently you didn't evaluate it all that closely, or you'd have noticed that you don't have to autogenerate schema from the objects. You have full control to manually write the db-to-object mappings.

Why Rails will win (0)

Anonymous Coward | more than 9 years ago | (#12134446)

Rails will win with the market because it is easy to find cheap [planetargon.com] hosting [textdrive.com] for Ruby on Rails. Not as cheap as PHP currently, but very reasonable already. Java lacks in this department.

Apache + FastCGI = cheap hosting

RoR == the mysql of web servers (-1, Troll)

kahei (466208) | more than 9 years ago | (#12134449)


RoR is absolutely unbeatable in code size, ease of use, and time to get started. Conversely, it is absolutely not there in scalability, caching, I18N, distributability, performance, documentation and so on.

In other words, much like Ruby in general, only more so.

It's like mysql -- brilliant if you want to put up something that works in a hurry. Not suitable for industrial-strength use.

I don't know how TFA got it's result of RoR being faster, but I suspect it's because the app in question is so lightweight. On a small app, the unneccessary crap that Java does (or if you prefer, the excessive simplicity of RoR) will have a decisive penalty but if you try and do a large amount of processing in Ruby you will pay a horrible price, compared to any modern JVM.

Second Time Around (1, Insightful)

Doc Ruby (173196) | more than 9 years ago | (#12134473)

Every time a good coder rewrites an app, it gets better. Especially a large, complex app. Ususally the new design insights afforded by a "warmup" cycle have to battle the tedium of repetition. But rewriting in a new language, especially one in which you're fluent, and interested in exploiting for performance, is a real motivator for optimization. I'd like to see comparitive benchmarks for another rewrite, *in Java*, to see how much performance gain is from the language, and how much is from the educational rewrite cycles. Deriving the motivator of "interest" is going to be harder, though still a factor.

Ruby DeRailed (1)

roman_mir (125474) | more than 9 years ago | (#12134479)

with the awesome /. powers

and now I can't read the article.

TFA (3, Informative)

daddyam (873272) | more than 9 years ago | (#12134488)

Some Numbers at Last

So, a few weeks ago I made an offhanded post here about my new-found love for Rails. I'd been skipping off the surface of Ruby for a while, trying to decide if it, or Python, or Groovy, or something else, ought to fill out the empty slot in my tool belt. (I'll save the "why LISP isn't on this list" post for another time.) Rails seemed like an excellent way to put Ruby through a workout, and I had the right sized project to try it out with.

The project itself is not open-source; the client is now and shall remain anonymous. But they are paying me my going rate to do this work, which makes it a commercial Rails project, and it will in the future be installed into some rather large organizations. I can't really say much about what the application's domain is, but I can lay out the general principles of the app.

The application must support multiple users, in the order of 10-100 concurrently. The load isn't particularly high, but the application will be treated like a desktop app (more specifically, a spreadsheet replacement) so it has to be responsive. The application is for managing pieces of a large machine process. There are lots of types of components to be managed, and the relationships between them can be quite complicated. There are no one-to-one relationships in the model, but plenty of one-to-many and many-to-many. In addition to managing the components, the application has to allow for the addition of entirely new categories of components as well as a variety of customizable fields. Finally, the authorization rules call for a breadth of user roles with a complex mapping of permissions to those roles.

I've finally gotten around to running the profiling numbers and doing some comparison between the two systems. I won't spoil the suspense by listing my conclusions up front -- you'll have to scroll through the rest of the post to see them. But, first, let me set the stage: the original application is based on the Java/JSTL/Spring/Hibernate/MySQL stack. I used ACEGI for the security, SpringMVC for the web controller, and was using Hibernate 2.x for the O/RM. To increase performance, I was using the default output caching from SpringMVC and data caching in Hibernate. The re-implementation is in Rails on top of MySQL. The authorization is done through a custom observer and a custom authorization class, which uses a declarative rules file for permission mapping. For performance, I'm using a combination of page caching, action caching, and cache sweepers (observers whose job it is to expire cached pages).

Now, for the comparisons:

Time to Implement
I made a comment about this in the previous posts on the topic, and that comment has been quoted widely out in the wide blogosphere as a classic example of Rails hype. So, let me make it plain: any time you re-write an application, it will go almost infinitely faster because you already have a firm grasp on the problem domain. Such was the case for me in my re-write; we'd spent so much time on the domain model and the database schema that the second time through the application, everything already made perfect sense to me. Any comparison of how long it took to implement one or the other is bogus, since the only fair comparison would be to implement two roughly functionally equivalent projects in the two different stacks and measure the competitive results. Since I have not done that, making statements about how it only took 5 days to re-implement the site are almost meaningless. What I can say is that I had more fun implementing it the second time, but that's just personal preference.

Lines of Code
This one is a lot more interesting. Folks will tell you all the time that there is a running debate about the meaningfulness of LOC comparisons. They're right; there is a running debate. I just think it's moot. For my money, the fewer lines of code I have to write to get a piece of functionality, *as long as those lines are clear in meaning*, the better off I am. Obfuscated Perl programs don't make the grade; I can write some really concise Perl code and not have any idea, three months later, what the heck I was doing. But if the code is legible, its intent obvious, then more concise is better, pure and simple.

Bear in mind that this comparison is somewhat unfair. The Rails version of the app has been in development for an extra month (meaning a month's worth of new features added) while the Java version has been stagnant since the switch. Since the Rails version started out as an experiment, I don't have a clear history of the codebase to be able to produce a version that is identical in features to the Java version. Therefore, I've made the comparison based on the current state of the app vs. the abandoned Java version.

The LOC counts used here do not include comments or unit tests, nor do they include simple punctuation lines (lines with just a "}" or "end").

Without further ado:

Lines of Code
Rails: 1164
Java: 3293

Number of Classes:
Rails: 55
Java: 62

Number of Methods:
Rails: 126
Java: 549

Configuration Lines
Rails: 113
Java: 1161

Those numbers are beyond striking. The configuration count alone is enough to make me think long and hard about what I've been doing lately. Let me forestall any criticism about my "agenda", by the way. Somebody recently said that I must have an "anti-Java" or an "anti-Spring" agenda. That is far from the truth, since my Spring: A Developer's Notebook hits shelves any day now. I don't want people to stop using Spring, or Java. In fact, I want lots and lots of Java developers to use Spring and lots and lots of non-Java developers to start using Java so they can start using Spring. But one of the things I like most about Spring (its concise configuration) is still, well, huge, compared to the same app in Rails.

Performance
This is where everybody really wants to see the numbers. So, for the sake of total specificity, the following numbers were generated on a 1.5GhZ Mac OSX (10.3.7) PowerBook with a 4200rpm hard drive and 1GB of RAM. The Java app is running on Jakarta Tomcat v 5.0.28, while the Rails app is running in Lighttp with FastCGI. The setups are standard for each application stack.

Since both stacks have different caching mechanisms, with different degrees of difficulty to manage them, I'll start the performance comparison with a walk through the application without using the caching systems. To generate the first number, I walked through every screen in the application (using the screens available in the Java version to form a subset of the screens available in the newer Rails version) hitting pages that have not been cached yet. This starts from logging in, then hitting every available piece of functionality once. These numbers do not include the time it took me (the user) to navigate to the next request, only the time to process the requests. Both applications had roughly equivalent logging turned on (obviously, it can't be exact, but without the logging, I couldn't provide measurements). Here's what I found out.

To walk the entire application feature set, once, in Rails, without caching, took 41.801s. To walk the exact same feature set in the Java app took 58.369s. These numbers are averages over five attempts with each app, with full restart between to give the cleanest runs possible. Those summary numbers are deceiving, though. What I found was that, the less complex the feature, the faster the Java app served it relative to the Rails app. The more complex the feature, the slower the Java app served it relative to the Rails app. Some of that difference might be changes to the model during the re-implementation based on a better understanding of the domain. Regardless, that difference comes out to show the Rails app at ~30% faster than the Java version when caching isn't taken into account. If I am generous and say that half of the difference is due to optimizations in the model, that still leaves us a 15% better performance in Rails.

The caching story is interesting. The default caching mechanism for Rails is either page caching (caching the output of the rendering to a physical html file and letting the server serve it directly instead of invoking Rails the next time it is requested) or action caching (similar, except the output is cached in memory or another kind of store and Rails is invoked to process the request). On the Java side, there is JSP pre-compilation, Spring output caching and of course Hibernate data caching. I used a simple load tester to test a couple of pieces of functionality in the application. For each URL, I ran the test without a pre-existing cache of the response, then again with it, 100 times each, and then determined the number of requests per second.

Functionality 1: Rails, 100 runs, no pre-existing cache: 75.59 request/second. Rails, 100 runs, pre-existing cache: 1754.39 requests/second. Java, 100 runs, no pre-existing cache: 71.89 requests/second. Java, 100 runs, pre-existing cache: 80.06 requests/second.

Functionality 2: Rails, 100 runs, no pre-existing cache: 62.50 r/s. Rails, 100 runs, pre-existing cache: 1785.15 r/s. Java, 100 runs, no pre-existing cache: 80.06 r/s. Java, 100 runs, pre-existing cache: 88.97 r/s.

These numbers are not a great comparison, because there is tons more I can do to increase the cache performance of the Java application. No doubt whatsoever (I just hadn't gotten around to it by the time I abandoned it). What *is* interesting, though, is that the Rails page caching maxes out . The server can't serve the pages any faster than that. And with the Rails cache_sweeper observer pattern, it is dead-simple to use this hyper-fast caching whenever possible (obviously, highly dynamic pages can't be cached, but that's the case with that kind of page in any application stack). If you switch to the action caching (which allows all the filters to be executed) the Rails app still ends up in the 800-1000 requests/second range.

Conclusions
So what do I think? I think that the application I'm working on is perfectly suited for Rails and Rails is perfectly suited for it. I think that I have had more fun working on the Rails app than the Java version. However, I think that the Java version is just as capable, and could be just as performant, as the Rails app. To me, the eye-opening revelation isn't "Rails is faster than Java/Spring/Hibernate". It's "Rails can be very fast". I think that there is a lot to be said for Rails, and it deserves much of the press it is getting. However, I don't think its a Java-killer. I think there are plenty of applications, and development teams, that are better suited to Java and its immense universe of available support libraries. I certainly am not going to stop developing in and learning about Java just because I've discovered Rails. On the other hand, I am going to spend more of my time trying to find projects that I can use Rails on.

I'm extremely interested in how these numbers strike folks, and whether there are other comparisons that you would find useful. So interested, in fact, that I'm risking blog-spamming by turning comments back on. So, if you have some other comparisons you would find useful, or some insight onto these numbers, or even some things you think I ought to try to make the comparisons better, let me know. I can't promise I'll tackle them all, but I think it will be interesting.

Meta-application issues (3, Insightful)

ewg (158266) | more than 9 years ago | (#12134497)

Improvements in performance and application size are always welcome, but there are some important outside issues to consider when picking a platform for your project.

One is, how deep is the library? With Java or Perl, there are libraries of open-source tools such as Apache Jakarta Commons and CPAN that often mean that with a quick download an enhancement request is 80% done. All new platforms (naturally) have a disadvantage in the department.

Another is, how easy is it to find developers with applicable skills? If an organization commits to Ruby and their Ruby developer leaves, how hard will it be to find a suitable replacement? This is a problem for all platforms except the juggernauts like Java, but especially new platforms. Looking at this another way, a platform choice can be a multi-decade committment. Choose carefully.

So the summary of the summary of the summary is that software development doesn't take place in a vacuum. Ruby is the coolest scripting language ever, but I can't recommend it until I learn more about its library and community.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?