From: Austin Ziegler Date: 2006-05-23T12:23:27+09:00 Subject: Re: Zed and Luis drop the bomb on Ruby's poor performance On 5/22/06, Madan Manoharan wrote: > (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 > 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)? Zed is but one of many "authorities" on Ruby. He's got certain experiences, but others -- and there's a lot of them -- have different experiences. Why should we develop *your* benchmarks to challenge something that consulting companies are lying about? If someone gives you benchmark results without publishing the source code for review and having independent verification of those results with properly tuned algorithms in both cases -- they are lying. It's sort of like the Alioth shootout (that someone has already posted about). There's not a lick of worthhile truth on that site, because there are implementations of algorithms that are unmaintainable (and other implementations that require esoteric hacks to get working). > The reason why IT managers want 'performance' even if the application > *really* doesn't require it, is to cover their behinds, among other > thing. For example, if the website is slow, they don't want it to be > attributed to the language, even if that is not the case (could be a > network problem, but the network group would more willingly point > their fingers at the app. development group for their choice of > language than to accept their problem); has happened before and will > happen again. Then you need to have stronger IT managers. The development group should be familiar with various profiling tools if they have an asinine network group who points fingers without absolute proof. Sorry, but it's true. Performance of a website/application is the responsibility of the entire company. > So, here 'performance' is not for the sake of performance demanded by > the application, but for the sake of 'not wanting to be talked to by > the boss'. That is the reason I said that many IT managers make > 'performance' decisions based on 'feelings', not necessarily had data. It is usually bad data, though. > (2) Using two different languages for different performance needs: > Some fellow Rubyists have said that they would switch to C if their > app. needed performance boosts. This will work if it is a personal or > small project. 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. Combined that with the mantra 'Java is fast' preached by many > consultants, and the decision for the senior IT manager becomes easy: > one language that can be used for apps that require *real* performance > and for ones that don't: Java. This is not correct. I have worked in several companies and have used, over the years, no fewer than fifteen languages. We use the language that is most appropriate to the task at hand. Now, switching between Java and C is a maintenance nightmare because JNI sucks so badly. (Remember: those same consultants who are now preaching "Java is fast, Ruby is slow" were the jackasses a decade ago who were preaching "C++ is fast, Java is slow".) > (3) Survival of Language: This is another bigee. If the IT manager OKs > a language that happens to be a fad, then he might as well bid goodbye > to his job (lost productivity, cost, etc). So, they want to be sure > that the language is going to be in the 'main stream' for a long time. > In their mind, the only way they can be assured of that is: This is the least worry. Ruby will survive with or without "enterprise" support. > A good case study would be on how Linux got its foot hold into the > corporate world. Usually? Through the back door. > 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. Then that would be your mistake. Know the battles you can fight. Prove Ruby useful and its use will grow. > On the other hand, if Ruby has a dream of penetrating the corporate > world, then it needs a marketing machine that would deal with the real > and, more importantly, the 'illusionary' problems created in the > corporate world -- just like Firefox's or Linux's marketing machine. > Unfortunately, penetrating the corporate world by *some* means is > never going to happen, unless an concerted effort is made. Fortunately, Ruby doesn't need this. -austin -- Austin Ziegler * halostatue@gmail.com * Alternate: austin@halostatue.ca