On 5/22/06, Madan Manoharan <madan.manoharan / gmail.com> wrote:
> On 5/22/06, Kirk Haines <khaines / enigo.com> wrote:
> >
> > The thing that always stands out to me in these performance discussions is
> > that people argue that Ruby needs a performance improvement, but there are
> > rarely any specifics attached to that analysis.
> >
> > How much of speed improvement?  How fast should Ruby be?  For what?
> >
>
> Please don't get me wrong, I really like Ruby. However, just because
> *I* like Ruby doesn't mean that I can start using it to develop
> applications within our corporation (I work for a large corporation).
> When I brought up using Ruby for application development with my
> senior IT manager, he was concerned about:
>
> (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)?

Read what Zed said about Rails app performance though.  Even though
Ruby can be slow, he said that with its built in caching, Rails apps are often
faster than Java Web apps.


>
> 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.
>

sorry, but if you don't have the logging/instrumentation to show where the
slowdown is, it doesn't matter what language you've written in.  Using
a languages because its marketing is better in order to "protect" yourself
is a good way to end up in bigger trouble down the line.  Profile, Optimize,
Log.   Hard, verifiable numbers will win everytime -- if they don't you've got
another problem.


> 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.
>

see above.

> (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.
>

you don't need to switch out the whole language.  Ruby uses C extensions
quite readily and they're not too hard to write (RubyInline makes it even
easier.)  You still get something that looks and feels like Ruby from the
high level view, only the bottleneck(s) have been replaced.



The remainder of this email is off topic to the general performance thread,
but I find it to be wrong-headed as well.  If need be, maybe we should start
another email thread to discuss Ruby and it's commercial support or lack
thereof.

> (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:
>        (a) if a large corporation is going to support it -- not
> necessarily the language, but any application build using the
> language. The thinking goes that if a large corporation is going to
> put its weight behind the language, then that corporation will not let
> the language die. This is what I meant when I said 'lack of corporate
> support for Ruby on Rails'; I don't mean to belittle the corporations
> that are offering support for Ruby on Rails, but I am talking from a
> large corporation's point of view. A good case study would be on how
> Linux got its foot hold into the corporate world.
>
> 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.
>
> 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.
>
> Just some thoughts from a guy who has been in the IT hot seat before,
> and is glad he is no longer there!
>
> Sorry for this long post.
>
> -Madan.
>
>


-- 
thanks,
-pate
-------------------------
http://on-ruby.blogspot.com