From: Stefan Matthias Aust Date: 2001-05-30T07:41:27+09:00 Subject: [ruby-talk:15969] Re: java based interpreter and regexes Sean Russell wrote: >Have you tried running the benchmark with Java 1.3 on your machine? Okay, I installed jarkata 1.2 and run the test: Time says 9.5s. Just to compare, "time ruby ..." says 4.7s. >I'd argue that this is Java's problem, since Swing is the defacto GUI for >Java, and the *apparant* speed of Swing applications is what is important for >end-user applications. Well, then Ruby's problem is called Tk. I'd separate the language from its libaries especially if there're not core libraries but you could drop in replacements. For example, I once tried the gtk/gnome bindings for Java and this worked quite well. It was as fast as any other native gnome application and you couldn't tell from its speed that it's a Java application anymore. Quite nice. >This is, incidentally, also a stumbling point for Ruby, IMO. Tk is >orthoganal to AWT in my mind; Tk may not be hindering Ruby because it is >slow, but it is a fairly unattractive toolkit. Oh, yes, that was what I was thinking, too. >> The main reason is the way AWT interacts with the host os. Sun is >> slowly fixing this problem, but the problem is the event queue and how >> damage events are propagated. > >The main reason for what? The speed issue in Swing? Or the limited >capabilities of AWT? The speed reason. >> Java isn't interpreted. > >Actually, it is. This is the nature of P-code. JIT does allow compilation >to native code, but without JIT, Java is interpreted, albeit optimized in >pseudo-native code. Maybe you'd feel better calling it "translation", or >"code-morphing"? I don't see much difference. Well, all major Java implementations nowaday feature a JIT. And it all depends on your point of view. A pentium class processor is also just an interpreter for x86 code which is Just-in-time compiled into micro code that is eventually executed by that system. bye -- Stefan Matthias Aust \/ Truth Until Paradox