From: Adrian Howard Date: 2006-05-23T17:29:30+09:00 Subject: Re: Zed and Luis drop the bomb on Ruby's poor performance On 22 May 2006, at 18:10, Madan Manoharan wrote: [snip] > (1) Performance: Here, the question is NOT about 'how fast should Ruby > be', but is about what people who have the capacity to make > 'significant' corporate decisions are 'being told' about Ruby's > performance by consultants. I have seen presentations by > 'well-established' consulting companies that show Ruby's performance > to be an order of magnitude slower than Java for web apps. I don't thing Ruby is an order of magnitude slower than Java in real world usage for web applications. It certainly doesn't match my experiences. Slower maybe, but not by an order of magnitude. If somebody said that to me I'd want to see more detail on the architecture, benchmark process, etc. [snip] > I don't have time to develop benchmark tests comparing the two > languages, but have to depend on Ruby app. developers to produce > those benchmarks; unfortunately I cannot find them easily. Now, Zed > (I would consider him an authority on Ruby) comes out and talks > about performance issues with Ruby (and YARV will solve it in the > future). How am I now to convince my manager that Ruby is > 'better' (within the context of performance)? You can't without more work I'm afraid. Because "performance" without context is meaningless. Remember when Java was introduced? "A virtual machine? Garbage collection? All this useless academic object-oriented nonsense introducing tons of wasteful indirection. Good grief it runs an order of magnitude slower than my finely crafted C code!" Guess what. Most Java is /still/ significantly slower than than finely crafted C code. Of course nobody cares :-) Nobody cares because for a significant number of domains: * you can develop applications of better quality more quickly and easily in Java * raw language speed doesn't matter because it's masked by issues like blocking for IO * hardware is cheaper than programmers And for those domains where raw speed is still an issue - there is still C. > The reason why IT managers want 'performance' even if the application > *really* doesn't require it, is to cover their behinds, among other > thing. [snip] > That is the reason I said that many IT managers make > 'performance' decisions based on 'feelings', not necessarily had data. [snip] Yeah - people who don't make decisions based on reality are a pain. Your options are: * ignore / work around them * get them relocated :-) * wait until everybody else is in the far end of the adoption curve Because waiting until everybody else proves that a decision is "safe" is the only way to convince some people. Sorry :-( [snip] > But when in an large corporation, switching between > languages to get performance gains will result in maintenance > nightmares. Many IT managers understand this and have experienced > this. [snip] Yet many other IT managers have experience of multi-language applications that work jolly well and are have been maintained successfully for years. I know I have. Odd that... > A good case study would be on how > Linux got its foot hold into the corporate world. [snip] In exactly the same way Ruby is. By doing some things better and cheaper than the alternatives. By there being people who spotted this and choosing the better alternative despite the wisdom passed down by "the consultants". By people seeing it working and going "hey - that could well work for me". By this group getting slowly larger over time until larger organisations can't ignore it and start adopting Linux themselves. > Once again, if Ruby's vision is *not* to penetrate the corporate > environment as Ryan pointed out (but would be a nice validation if it > indeed penetrate the corporate world by *some* means), then this > discussion is moot. Knowing that, I wouldn't try to push Ruby to my > managers; I will use it for personal projects. Suit yourself :-) Personally my vision is to do the best job I possibly can for my own self respect, and to make the company money (and me some cash too - indirectly). That means I'm going to be picking the most effective solutions I can find. This means I am going to be looking hard at Ruby for use in the places we are using Perl and Java now. In fact, now I think of it, please don't push Ruby too hard. You might be a competitor :-) Cheers, Adrian