From: Ben Christensen Date: 2009-08-20T14:25:58+09:00 Subject: 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/.