From: Russell Mok <rmok@...>
Date: 2001-11-13T10:04:09+09:00
Subject: [ruby-talk:24967] Re: Why is ruby slow (compared to perl)

Sean Russell wrote:
  > No, I'm assuming that in some cases, the most important criteria of code is 
  > the speed of execution.  Furthermore, I'm rebelling against the trend I see 
  > to completely ignore issues such as speed.  I'm hyper-sensitive, I suppose, 
  > because I've been coding exclusively in Java for the past 7 years, and I've 
  > seen what a difference speed can make in the general acceptance of any 
  > software.  The most beautiful, functional code is absolutely worthless if 
  > it isn't used because it is too slow.  On the other hand, fast code will 
  > tend to be used even if it is really, really.  In the end, the users (whom 
  > we're writing the software for) don't care what the code looks like; they 
  > just want it to work right and run fast.

Here is a C++ programmer's view.  There is definitely a cost of using
OO (virtual function).  However, you don't need to use virtual
functions everywhere (at least in C++).  What we want is loose
coupling, encapsulation and it can be achieved in many ways (and this
is why C++ many features missing in Java).  Java is slow compare to
C++ because it doesn't have value objects (eg. complex numbers in C++
is implemented without using OO, it's just object-based programming).
C++ programmers believe that virtual functions should not be public
(see Herb Sutter column 'Virtuality' in C/C++ User Journal, it appears
after the July issue but can't tell the exact issue).  I think Java
programmers is on the opposite side.

Think about this.  OO (or inheritance) is the highest coupling feature
(besides friendship in C++) and overusing doesn't help decoupling your
software.  In C++ and Java, they impose additional runtime costs.
Generic programming can complement OO in a nice way.

Also, refactoring is about design/concepts more than coding (I doubt
that every XP programmer is refactoring all the for loops), and even I
refactor a piece of code in C++, it doesn't have to be slower because
of compiler inlining.  However, I have seen refactoring in OO and I
have to agree with you it can be a performance killer if it is being
done blindly.  In pure OO, refactoring has to introduce a level of
runtime indirection (in the context of Java and C++).  The refactored
classes usually have small virtual functions to serve a very small
task.  These virtual functions prevent inlining, and potentially
increase the memory footprint.  The idea of Java interface (as what I
know) forces people to use inheritance and public virtual functions.
You can say these are the tradeoffs (if not design flaws) in Java.
ACM Communications recently has an issue of aspect oriented
programming which also has a few articles about high performance Java
(or issues of that).

Ok, I should mention sth about ruby.  The original was about perl
being so much faster than ruby on win32.  Besides the Cygwin vs
Visual C++ issue, is it true that Ruby is an interpreted language and
Perl is a compiled/interpreted hybrid?  If so, Perl's performance
advantage over Ruby should become bigger when a similar task takes
longer.

Russell