[LRUG] Speed cameras...

[Eleanor]

On 29 Jun 2006, at 22:08, Adrian P Challinor wrote:
> I came to Ruby/Rails because I was tired of the EJB bloat and the  
> amount of
> crud I needed just to get what I thought were simple java systems  
> built. I
> have had this feeling that Java started off quite fast, but the  
> number of
> layers it has to go through to get anything done was slowing current
> production systems down.

Just for the memory footprint alone Java annoys me. There have been  
some studies that have shown the latest JVM to be on a par in terms  
of runtime speed with current C++ implementations, but then again I  
find it hard to believe that modern C++ is anything but bloatware.

> I have found Ruby/Rails suprisingly efficient - all the more so for  
> the fact
> it is interpreted and doesn't go though a partial compile as Java  
> compiles
> to byte code.

Ruby performs acceptably for a traditional interpreter and has a nice  
extension layer so that anything that seems slow can always be  
abstracted and implemented using C so most of the slowness can be  
removed with relative ease. The number of Ruby extensions coded this  
way is in marked contrast to the number of native Java extension  
libraries...

To be honest the benefits of bytecode for improving runtime  
performance are patchy. The JVM implements a fairly conventional  
stack machine architecture which is part of the reason why JIT  
compilers are so popular, but the instruction set is a low-level one  
and quite inefficient for representing a high-level language. This is  
fine for Java as obviously it's designed to be a systems' programming  
language, but that's also the reason why it's so verbose.

Ruby's succinctness, like that of Lisp, is a reflection of a higher- 
level abstraction better suited to how we as humans think rather than  
how computers process data. Consequently the interpretation of the  
code contained in a given program is likely to be much less onerous  
than with a program written in Java to solve the same problem with  
only heavy mathematical computation likely to suffer a significant  
performance hit. Whilst Rite will hopefully redress the balance in  
this regard, I don't think that most web applications will notice  
much of a performance boost from bytecode compilation - and in the  
meantime anyone doing serious number-crunching would probably choose  
to move the critical code into a C extension.

Ellie

Eleanor McHugh
Systems Developer
http://www.telnic.org/