Re: Confirm my Performance Test Against Java?

Edging away from the data driven performance analysis, I'd like to 
explore some of my more subjective and opinionated thoughts on the 
matter since several of your answers have touched on them. I'd very much 
appreciate your rebuttals to my following comments (if you feel like 
spending the time reading and responding).

I am obviously biased by my long use of the Java platform, and very 
likely by my many years of focusing on processing large amounts of data, 
writing search engines and other such applications very sensitive to 
performance - and thus I have profiled and optimized virtually every 
aspect of the stack and code - and to great gains for the user 
experience. On the other hand, I've also connected to mainframes where 
no amount of code optimization on my end could make any difference in 
how things performed as I depended on the result from an external 
resource, and I hid that from the user as much as possible with 
asynchronous user interface magic as opposed to worrying about code 
optimization, language choice or even hardware.



## Fast Enough ##

I often hear that Ruby is "fast enough" or that the performance 
difference is not important since IO is generally the real source of 
performance issues.

I understand that in certain cases - though when I see potential 
performance degradation as multiples (2x, 3x, etc) as opposed to small 
percentages, it makes me question the decision to use Ruby much more 
than if we were talking percentages of 10-20% - such as 115ms vs 100ms 
on a page response.

For example, a java environment my team has built provides SOAP/REST 
webservices for product catalog search - and responsiveness is a very 
significant measurement criteria of the success of the product and 
system. Therefore, our average server side response time is something we 
watch very closely.

It's difficult for me to accept the use of a language or platform which 
means I'm taking a significant hit in performance - similar to the first 
5-8 years of Java.

Even Java is still improving ... Java 5 to Java 6 was a very noticeable 
improvement in performance at the JVM level (I've had 30-80% performance 
increases from 5 to 6). Same hardware, same code - noticeable 
improvement in performance and thus responsiveness on webservices, 
webapps and shorter data processing times.

In the late 90s it was worth it to me to use Java and take the 
performance hit - as the benefits were so strong over C for so many 
things.

However, I'm still struggling to see the strong reasons to adopt Ruby 
when I'm penalized performance-wise and the answer becomes "it's good 
enough" or "network IO is usually the slowest aspect, so it's negligible 
what Ruby adds" or "CPU is cheap".

Yes, "CPU is cheap", but that applies to Java as well. 6 months ago we 
upgraded our hardware (systems were only 18 months old when we upgraded) 
and shaved off another 30% just by taking advantage of new CPU 
architectures and bus speeds that had changed in the previous year.

Perhaps in a straight-forward CRUD app where all that's being done is 
retrieving/storing data in a database where IO truly is the bottleneck 
that no amount of optimization can improve - then it doesn't matter and 
"good enough" rings true where IO takes 100ms and the Ruby/Java portion 
is only 10-20ms on top of the IO.



## C Extensions to Ruby ##

This feels akin to saying in the late 90s that to make Java perform 
well, use JNI to use C. To me it defeats the whole purpose of the "Ruby 
is simple and pleasant" paradigm. If I have to optimize it with C, then 
it's no longer simple or a joy to use.



## Maintainability, Speed of Development and 'Enjoyment' ##

I hear "speed of development", "maintainability", and "enjoyment of 
coding" as the reasons to move to Ruby - and to accept the negatives in 
performance, tools, libraries etc.

I'm still not sold on these reasons - as I truly enjoy working in the 
Java ecosystem of tools, projects, libraries etc - despite what may or 
may not be "crufty" or verbose in some aspects of the language itself.

Nor am I convinced yet that managing a codebase over 5-10 years and 40+ 
developers is any easier with Ruby - Java's static typing and now its 
generics (the polar oppostite approach of 'duck typing' in Ruby) are 
actually very nice for readability, navigation of code, refactoring and 
other such things on such large codebases when so much of it is from 
other coders, teams, or just plain old and forgotten about.

Putting aside these more subjective decision points that I do not yet 
have the experience to weigh in on with Ruby - if the performance impact 
affects the end user, then that is in my opinion an objective point of 
concern. Google and Amazon have both publicized how slow downs of 
100-300ms on a user interface affects user experience and how much those 
users utilize their sites. I certainly recognize that fact while 
operating a hosted search engine. Speed of search directly impacts how 
much someone will choose to use it. Slower performance equals increased 
friction to use.

Also, no amount of "throwing hardware at it" will make Ruby faster than 
throwing the same hardware at Java - which is ultimately I think the 
biggest issue I have with the concept. If I throw the fastest hardware I 
can at something, I want my user to get the biggest bang for the buck - 
not just make up for me using a slower language.

As for "brevity" equalling "maintainability" and "less bugs" - I tend to 
disagree when the pursuit results in code such as this example given:

    puts "The number of tokens is: %d." % File.open(ARGV[0]){|f|
    f.inject(0){|a,l| a+l.split.length } } ,
      "It took #{(Time.now - start) * 1000} ms"

I find it intellectually stimulating and admirable at the power of what 
is accomplished in such a short statement.

Understanding it however takes time and thought - and a certain level of 
skill.

Perhaps your experiences are different - but most development teams have 
a lot of more junior and intermediate developers than senior - and the 
more verbose, easy to read, simple to understand code is far more 
preferable - even for myself when I must review, debug and profile the 
code of dozens of others - as opposed to something that looks like an 
academic puzzle to unravel.




## Concluding Thoughts ##

I recognize that many of my concerns are similar to the C versus Java 
argument of 10 years past.

Moving to Java from C had a variety of very significant benefits 
however, amongst them being: garbage collection and vastly simplified 
memory management, no need to worry about pointers, "write once, run 
[mostly] everywhere" (as long as you were talking server-side and not 
desktop where Java is miserable) and APIs designed better to address the 
networked world of the then new (to the common public anyways) internet.

In moving from Java to Ruby I don't see the benefits as strongly 
motivating - and therefore am much less willing to accept performance 
penalties.

In short, after waiting through 10+ years of maturation to get the Java 
performance now enjoyed, it feels somewhat odd to step back 
significantly in performance, tool maturity and available libraries.

What types of applications and codebases do you feel truly are served 
best by Ruby - and therefore not in need of the highest performance 
given to the end-user?

-- 
Posted via http://www.ruby-forum.com/.