«

> I suspect, but I may be totally wrong, that Java takes a while to
> 'warm up' a more complex runtime environment, and that Ruby gets going
> faster. =A0The JVM has evolved in an environment where it has tended to
> be used for long-running processes.

Put in a few require statements, load some gems in the ruby source and
then repeat the comparison. The last time I checked, e.g., groovy's
startup time was comparable to ruby's.

[Note: parts of this message were removed to make it a legal post.]

On Thu, Aug 20, 2009 at 11:22 AM, Ben Christensen <
> wrote:

> -- You won't really get a taste for what we mean until you start writing
> -- Ruby (real Ruby, not Java ported line-by-line to Ruby).
>
> What example opensource projects can you refer me to which espouse the
> "real Ruby" style of doing things?
>
> I'd prefer non-Rails projects, as I understand the completely different
> approach of webapp dev with Rails.
>
> I'm looking specifically at Ruby.
>
> I keep getting told that I must understand the "Ruby way" - so I'd
> appreciate instruction on how to accomplish the "Ruby way" considering I
> am apparently boxed in as a "Java/C style programmer" ... despite
> disliking C
>

Hi Ben,

Three books come to mind when discussing "real Ruby" style:

"The Ruby Way", by Hal Fulton: http://isbn.nu/9780672328848 (The oldest of
the three, and I don't *think* it covers 1.9)
"The Well-Grounded Rubyist", by David A. Black: http://isbn.nu/9781933988658

"Ruby Best Practices", by Gregory Brown: http://isbn.nu/9780596523008

For projects, I'd recommend Rake or FasterCSV. There are no doubt many, many
more, but those two are written by very well respected Rubyists, and are
also in widespread use.

HTH,
Mike

On Thu, Aug 20, 2009 at 8:52 PM, Ben
Christensen<> wrote:
> -- May I then ask what made you consider Ruby in the first place?
>
> The reason I'm considering it is because I don't want to blindly choose
> Java just because it's the default.
>
> As for why Ruby and not Erlang, Scala, Groovy etc -- the honest answer
> is because Ruby is getting so much attention these days, to the point of
> religious fervor amongst many I speak to that I need to take an
> objective look at it and what it does well.

If speed and static typing are must-haves, and if you have already got
a lot invested in the jvm, scala is very well worth a look. It also
has some features that let you write concise, maintainable code in
much the same way that you could with ruby.
http://www.cordinc.com/blog/2009/04/...rs-in-jav.html
is an interesting look at the same task implemented in all three
languages.

martin

Thank you Martin and Mike for the book references, I will go pursue
further education on the subject from those.

This thread has been very instructional to me and I appreciate your
willingness to discuss this subject.

Have a nice weekend everyone.

Ben
--
Posted via http://www.ruby-forum.com/.

[Note: parts of this message were removed to make it a legal post.]

Ben,

Thanks for provoking a productive discussion.
I think we all agree that Ruby is slow, very slow, and my impression
is that you underestimate the slowdown.

But ...

The "is Ruby fast enough?" discussion suffers from the same flaws as
many that precede it ( Fortran vs Assembler, C vs Fortran, C++ vs C, C+
+ vs Fortran, Java vs C++ ...)

The discussion rests on some faulty assumptions:

That language runtime performance will dictate system performance. In
fact, rarely is that true and in performance engineering the truth is
much more farcical than anyone might think...

The first time I was paid to write Fortran code I'd been warned that
Fortran would be unacceptably slow compared to Assembler. It didn't
matter. I simply was not capable of writing sophisticated time series
analysis code in Assembler. In fact a large part of that project was
built and deployed with GW-Basic on a 6MHz 8086 CPU with 512K of RAM.
As a newbie programmer I didn't realize that an interpreted language
could not perform, and the app successfully predicted windshifts in
real time in about 5% of the time that been budgeted. Perhaps with
more work experience I would have known better

Since then I've done a bunch of performance critical coding and, over
the past few years, a bunch of tuning work.

Ruby's 3x performance penalty is enormous.

But it's dwarfed by the performance degradation caused by typical
coding and typical physical architectures.

Two real, typical datapoints, from a list of hundreds ...

In Dec 2008 I tuned a production Rails app that had 100,000 users,
improving the client side build time, for the test page,
from 2.2 sec to 181 ms, (a factor of 12). In an appendix to that
project I identified more than a dozen unimplemented tunings that
could further lower that build time to about 7 msec.

In 2003 I worked on a similar Java project, and spent much longer
tuning a similar dynamic page (running on much slower hardware). The
team implemented more than 500 performance fixes over six months,
improving page build times from approx 2.5 sec to 14 ms (a factor of
180x).

Neither app was built by weak programmers - in fact they were two
extremely smart development teams.

So when you describe a web service that responds (server side) in 140
ms, and ask why you should consider a toolset that might triple that
response time, I ask

"has someone else deployed a similar web service that responds in 2
seconds?"
"has someone else deployed a similar web service that responds in 2 ms?"

"what would it take for it to respond in 20 ms?
"what would it take for it to respond in 5 ms?"
"what would it take for it to respond in 1 ms?"

I hate slow code and slow websites and I resent the time I waste
waiting for both.
But our industry norm is for system response times to be 100x or
more slower than they need to be.

You might think "BS", or "OK, but he's talking about the doofus
programmers, he's not talking about us."

I'm talking about you, me, all of us.

I don't know anything about the web service that you describe but I
will happily wager $50 that we can take any Java web service that is
currently running in production, and replace it with a Ruby equivalent
that is twice as fast.

Note that I'm not saying "I can". I'm saying that you, me or any smart
programmer here can do this.

Here's the thing - I've worked on at least a dozen platform rewrite
projects, going back more than 20 years (
"we need a C version of this hand optimized assembler file IO layer"
"Hey build a Java version of this C++/X app",
"we need a web version of this desktop app",
"we need a script version of this compiled app").

Typically there's an accompanying message that management understand
that it might be twice as slow.

On every single occasion, the surprising outcome is that the new
version, built with a higher level "slower" toolset, outperformed the
"stable, optimized, tuned" version, typically by a factor of 3 or
more. So I'd be a fool to continue being surprised by this. I'm not
saying that I'm a better programmer than anyone. I am saying that the
amount of wasted resources in most deployed systems is much, much
higher than people realize, for a whole set of reasons.


Thanks for initiating such an interesting conversation, and for
persisting with it.

Peter Booth.

Peter,

Taking your experiences one step further, wouldn't it stand to reason
that if a system is being "rebuilt" with all of the lessons learned, but
with the mature "faster performance" language, that it could achieve
higher performance than being rebuilt in a new, less mature, "slower
performance" language?

Your well-founded arguments suggest that many (if not the majority of)
performance issues are in poor design and implementation - not the
language itself. I agree that this is often the case - I find and fix
many of them in the systems I profile. A recent example was an issue
causing 2 orders of magnitude in performance degradation because of
absolutely horrible design - nothing to do with any type of language,
platform or infrastructure.

But if a system is being built by a team capable of achieving the
performance gains you claim with a "slower" toolset, if given a "faster"
toolset, would that same team not accomplish an even better performing
end result?

Of course, I'm not suggesting a difference as extreme as Assember and C
- which is such a different paradigm that this comparison is very
difficult to do.

Current languages though are so often variations on a theme - rather
than revolutionary changes in approach. For example, working with Ruby
doesn't leave me feeling like I've just experienced some nirvana -- it
feels like just a different approach to things that may or may not
benefit certain tasks -- but principally is not so different from Java
(or Groovy, Scala, C#, Python etc) as to make me feel something earth
shattering has occurred.

Thus, if a team equally skilled in both Ruby (and its "way" of doing
things) and Java could approach a project and avoid the design pitfalls
that cause most of the performance issues you have stated - then
wouldn't the team accomplish higher performance with Java?

Ben
--
Posted via http://www.ruby-forum.com/.

On Thursday 20 August 2009 10:22:39 am Ben Christensen wrote:
> That being said, I am trying to figure out what the "Ruby way" is -
> which so far is far from clear to me.
[...]
> What example opensource projects can you refer me to which espouse the
> "real Ruby" style of doing things?

I can't think of any particularly good examples, mainly because...

> unless it's a small team
> of very competent people who all believe in the same paradigm and treat
> their code as art.

I was part of just such a team. We built a set of semi-formal rules, and an
always-outdated document about coding style. Mostly, though, our coding style
evolved together because we were always in each other's code and over each
other's shoulder.

So, unfortunately, I've developed a very visceral and intuitive sense of what
"real Ruby" should be, what's idiomatic, but I find it difficult to express.

I can point to a few things you've probably heard:

- Duck typing. The type and class hierarchy is completely irrelevant. All you
care about is whether the object in question responds to a particular method.
(This means you should more often use #responds_to? rather than #kind_of? if
you're testing your arguments at all.)

- Encapsulation. Not as in enforcing what's private, because you can't
(there's always #send and #instance_variable_get), but as in, push the logic
back into the appropriate object, rather than into something operating on that
logic.

- DSLs. Or, less buzzword-y, define what you'd like to be able to do, and then
figure out how to do it. Go by what's most expressive, and most sounds like
English -- treat code as communication. "Code like a girl."

- Don't Repeat Yourself.

I can give you some extreme examples: Rake (or even Capistrano), Hpricot (or
better, Nokogiri), Sinatra, Markaby, and Rspec (or test-spec, etc).

I'm not suggesting you read the source of all of them. Rather, see how they
might be used. Sinatra is a particularly powerful example, especially combined
with Markaby -- though I prefer Haml for real projects. Rails is a fine
framework, but it's beautiful to see a framework dissolve into nothing more
than:

get '/' do
'Hello, world!'
end

> For example, if both Java and Ruby both performed single threaded
> transactions at 150ms each, and both scaled to 10 concurrent threads
> equally well, but Java continues to scale to 30 concurrent threads and
> Ruby does not, then that's a scenario where I can add 3 machines to
> scale Ruby horizontally and truly argue that the cost of the hardware is
> more than made up for by lower developer costs.
>
> But, "per request" performance does not get improved by this type of
> solution.

A good point. Still worth investigating whether Ruby can be "fast enough" for
this. Just for fun, here's a quick presentation:

http://www.slideshare.net/wycats/mer...e-presentation

This is also relevant, as there are plans to merge Merb and Rails at some
point, while retaining the advantages of Merb -- particularly performance.

> Adding faster hardware does not make Ruby catch up to Java - since Java
> also improves with faster hardware.

Yes, you've said this before -- but it doesn't have to. Take your example
above -- if you can get Ruby under 150 ms, that's good enough. Adding faster
hardware gets Ruby under 150 ms. If it gets Java down to 30 ms, what's the
point?

> It provides a better use experience to the user and (according to Google
> and Amazon) increases their usage of the system.

I'm curious what the threshold was for this to make a difference.

Certainly, at a certain point, it doesn't. The difference between 16 ms and 0.6
ms would actually be invisible to the human eye. But while 100 ms vs 50 ms may
make a difference, I'm skeptical. Users are annoyed at having to wait a tenth
of a second for a response?

> The speed at which an application responds to an end users request
> impacts the overall usability of an application.
>
> It is for this same reason that things such as network compression,
> network optimization (CDNs, Akamai route acceleration etc) and client
> side caching also all play a role.

These all make sense -- Akamai in particular -- in the context of having a 100
ms response instead of, say, 500 ms or a full second, or in the context of
scalability.

> -- when was the last time the type system saved you?
>
> It's the toolset as you stated that you suspect.
>
> The readability of code to know exactly what types a given argument,
> variable or array contain.

To me, this falls back into Duck Typing. What type does this argument contain?
Why is this a meaningful question? If I want it to contain a string, for
instance, all I really need to know is whether it responds to #to_s.

More likely, it's a more complex object, but it's still the behavior that I
care about, not the type of it. And this intuitively makes sense -- in the
real world, also. When making a hiring decision, do you care about the "type"
of the person -- their degree, their sex, their skin color? Or do you care
what they can do, and how they'll interact with the rest of the team?

Yes, the degree may be an indication of that, but it's not really what you
care about. And certainly, the other things I mentioned shouldn't enter into
the equation at all.

> For example, code completion in these tools to suggest the available API
> methods is almost useless, as they offer virtually every method
> available under the sun, as they are not interpreting what actual type
> the variable is.

Because it probably doesn't have one yet.

While it's a bit different, try running an IRB shell with your favorite
framework loaded and some sort of tab completion. It won't be perfect, but
it'll probably work.

In the mean time, I'm going to say that it isn't an issue for me, simply
because if the framework I'm using is so complex that I need code completion
for daily work, I'm probably using the wrong framework. I can think of some
times it would've been convenient, but not nearly worth having to use one of
these other languages.

> Therefore they'll show me 15 different versions of a
> method with the same name, all for different object types from the Ruby
> API.

Any one of them would probably have been a starting place.

> Thus, I must now depend on a team of developers properly documenting
> everything, using very descriptive naming conventions (and properly
> refactoring all of that when changes occur), and wrapping everything in
> unit tests.

These are things you should rely on anyway.

No, not Hungarian notation, but calling the variable something more
descriptive than 'a' and 'b'.

> Now, all of those are "ideal" cases - ones I believe in and stress
> continually. I have hundreds and hundreds of unit tests and automated
> build servers etc - but in the "real world", getting teams to comment
> every method, properly name (and refactor) variable names and cover
> everything in unit tests just doesn't happen

I don't comment every method. I should comment more than I do, but for
example:

def writable_by? user
# ...
end

Tell me you don't at least have a guess what that does.


> -- 100 lines of code is generally easier to read and
> -- debug than a thousand.
>
> I'll give you that - but I have yet to see anything that proves to me
> that a competent developer using both Ruby and Java (or C# for that
> matter) would have 10x as much written code than they would in Ruby.

It's probably an exaggeration, but not much, though I admittedly have limited
experience in Java. But as an example, how much time do you spend writing
interfaces? Maybe it was the nature of the assignment, but I would guess
easily 20-30% of my time doing Java in school was doing things like writing
interface definitions.

That whole file becomes irrelevant in Ruby.

And I would say the same for Ruby or Python, and to a lesser extent, Perl and
Lisp -- it does end up being _significantly_ less code. I'm learning Lisp now,
and this book:

http://gigamonkeys.com/book

opens with just such an anecdote:

"The original team, writing in FORTRAN, had burned through half the money and
almost all the time allotted to the project with nothing to show for their
efforts... A year later, and using only what was left of the original budget,
his team delivered a working application with features that the original team
had given up any hope of delivering. My dad credits his team's success to
their decision to use Lisp.

"Now, that's just one anecdote. And maybe my dad is wrong about why they
succeeded. Or maybe Lisp was better only in comparison to other languages of
the day..."

I could say the same -- certainly Java is going to be better than FORTRAN. But
you'll still occasionally find the story of the team which beat everyone to
market, or swooped in and rewrote a failing project, or won.

> The "cruft" so often referred to are things that I don't even consider
> or think of. Boilerplate code ... clutter and sometimes annoying ...
> fades into the background and tools remove the pain of it.

I don't think tools would remove the pain of looking at it, at least -- and
yes, it is annoying. Even if the language is going to be statically typed,
consider the runtime exception. If the Java compiler knows enough to know that
I forgot to declare what type of exceptions a method might throw, why do I
have to specify them at all? If it's for the sake of other developers, why
can't the tool tell them?

After all, there are going to be plenty of methods which really wouldn't care
about exceptions -- just let them pass through, let some other layer handle
them.

I also find it telling that with Ruby, I can get by with just a good text
editor -- TextMate for OS X was excellent, though I now use Kate on Linux --
whereas with Java, I would pretty much need a tool just to remove the pain of
the language.

> Amazon referred another book called "The Ruby Way" which may also
> provide me good insights. Any experience with that one?

None. I did read a book called "The Rails Way" which was excellent, and seems
to be from the same series, but by a different author.

> In fact, I'm trying to figure
> out how to rip Java out of my webapps completely and leave that to the
> backend webservices and let the presentation layer be as free from
> "code" as possible.

Look at Haml and Sass. You'll either love it or hate it.

> For example, if I can accomplish a dynamic front-end purely driven by
> client side Javascript using AJAX techniques with a REST style
> webservices backend, I will try to pursue that.

I like jQuery for this. Rails and Merb seem to be moving back towards
integrating this kind of thing -- "link_to_remote" is an old-school example,
and I suspect we'll see more of this sort of thing in the future.

I've also been a big fan of replacing the X in AJAX with either JSON or HTML,
as the situation demands. While it's a bit sloppy, HTML makes sense in that I
can then have all the HTML-generation stuff in the server-side views, where
they belong, and the Javascript on the client is that much simpler. But if I
was writing a richer client, JSON would be ideal, at least until someone shows
me a decent Javascript Yaml library.

> The middle ground seems to be pursuing Ruby or something else that is
> still server-side, but better suited to the always changing pace of
> webapp dev and more creative, script driven coding style better suited
> to web developers and designers.

I think this would work well with the above. In particular, Rails has been
very REST-oriented for a very long time.

[Note: parts of this message were removed to make it a legal post.]

Ben,

I think the problem is that we are technologists, so we see our work
through a technical lens. But developing systems is a human activity.


On Aug 21, 2009, at 6:09 PM, Ben Christensen wrote:

> Peter,
>
> Taking your experiences one step further, wouldn't it stand to reason
> that if a system is being "rebuilt" with all of the lessons learned,
> but
> with the mature "faster performance" language, that it could achieve
> higher performance than being rebuilt in a new, less mature, "slower
> performance" language?

It wouldn't be true, but it might stand to reason. It would be
reasonable
for me to expect that Microsoft Word, on my Dual Core MacBook Pro
should be 100x as responsive as the first dedicated word processor
that I used 25 years ago

I think that, in general, systems are as slow as is physically possible
whilst still being "good enough." I suspect that the 2 or 3 orders
of magnitude
degradations are common today because of current hardware, and that 20
years
ago the same systems might be 1 or 2 orders of magnitude slower.


>
> Your well-founded arguments suggest that many (if not the majority of)
> performance issues are in poor design and implementation - not the
> language itself. I agree that this is often the case - I find and fix
> many of them in the systems I profile. A recent example was an issue
> causing 2 orders of magnitude in performance degradation because of
> absolutely horrible design - nothing to do with any type of language,
> platform or infrastructure.

My work has shifted in recent years from development to more short-term,
fire-fighting, performance work. I've found that to making a dramatic
performance improvement in minimal time requires being willing (and
able)
to work at all layers in the technology stack, from web page
construction,
application code, server configuration, physical architecture(what
runs where),
DB schema and query tuning, OS kernel tuning, TCP stack tuning, RDBMS,
physical network, hardware, hosting, virtualization, etc.

Unless I'm feeling jaded, I wouldn't say poor design and
implementation - rather
incomplete or nonexistent design and physical architecture, and flawed
implementation.
A positive spin on this is to say that 95% of startups fail, 70% of IT
allegedly fail,
thus it's a waste of effort to unnecessarily invest this time until
there is evidence that
the system will live.


>
> But if a system is being built by a team capable of achieving the
> performance gains you claim with a "slower" toolset, if given a
> "faster"
> toolset, would that same team not accomplish an even better performing
> end result?

Not at all. The same team that builds a web service that responds in
two seconds
is capable of building the same web service with a response time of
200 ms.
But what incentive do they have, if they don't have a 200ms SLA?

The "bloat factor" is not a measure of developer strength. It seems to
be more a function
of the expected performance, and how visible performance is.

Here's an example:

I worked on a project that had more than 100 developers building
"portlets",
tiny portal widgets that built a single piece of content. My team was
responsible for
performance. After a few months of furiously tuning everything we
could we made
a change that had a profound impact:

We reconfigured the integration instance of our system so that any
user would view
the build time of each portlet, as a small label on the frame of the
portlet. At first
build times ranged from upto a few seconds. Within a few days those
developers
whose code was especially slow were proactively asking experienced
architects to help
them fix performance issues. Within two months there were no portlets
building
in more than 100 ms. The force of social disapproval had a much bigger
impact than
buying ten licenses of a Java profiler.

> ... working with Ruby ..... is not so different from Java ... make
> me feel
> something earth shattering has occurred.

I was a bad/intermediate C++ programmer when I learnt Java. My
managers, who were
all much stronger at C++ would say similar things. Java did turn out
to be ground-breaking
despite looking visually so much like C++

The significance of a technology change depends upon how its used, not
just syntax or the obvious feature-set.
I think it took more than a decade to clearly see how Java had changed
things for developers.

In 2015 I will be happy to discuss whether or not Ruby makes the earth
move for me.


>
> Thus, if a team equally skilled in both Ruby (and its "way" of doing
> things) and Java could approach a project and avoid the design
> pitfalls
> that cause most of the performance issues you have stated - then
> wouldn't the team accomplish higher performance with Java?

No. Like the guy in the bar said, "If my auntie Velma had a pair,
she'd be my uncle ..."

I interviewed with two competing, secretive, equity option dealers in
2004. Each had a team of 3 or 4 developers
who had written their own automated trading system. These dealers
competed head to head and used
identical technology (Java, Linux on Intel), and both were
successful. The first place had identified that
equity options was an important business to them, knew that the US
markets would be most profitable,
and had provided the group with almost a blank check to get the job
done. They were proud of their
300 server cluster and the profits they made.

The other team was less optimistic and had a much smaller bankroll.
They didn't realize that the US was
the place to be so they tried to deal in all global markets. They
built a similar system to the first group
but they had a system workload that was about 10x that of the first
company. They were just as proud of
their home-grown system, which made them lots of money, even though it
was hosted on a mere 4 servers.

Two teams, similar background, built near-identical systems, and one
had a capacity that was
1000x the capacity of the other.

This is not unusual.


Peter.


> Ben
> --
> Posted via http://www.ruby-forum.com/.
>

[Note: parts of this message were removed to make it a legal post.]


On Aug 23, 2009, at 6:08 PM, David Masover wrote:

> On Thursday 20 August 2009 10:22:39 am Ben Christensen wrote:
>>
>
>> It provides a better use experience to the user and (according to
>> Google
>> and Amazon) increases their usage of the system.
>
> I'm curious what the threshold was for this to make a difference.
>
> Certainly, at a certain point, it doesn't. The difference between 16
> ms and 0.6
> ms would actually be invisible to the human eye. But while 100 ms vs
> 50 ms may
> make a difference, I'm skeptical. Users are annoyed at having to
> wait a tenth
> of a second for a response?



I've spent some time trying to understand this. My impressions ..

Human Factors Research says:
A response is perceived as instantaneous if it occurs within 0.1 or
0.2 sec
A response is perceived as immediate, and won't interrupt
concentration, if it occurs within about 0.5 to 1.0 sec
If we speed up a website, then a change thats less than 7% to 18%
wont be discerned by a user.

The State of the art
Google measured that a 400ms slowdown measurably reduced the number of
searches per user by 0.76%
Shopzilla invested in performance tuning their website and saw revenue
increases of 7 to 12%
Bing saw measurable changes in user behavior with slowdowns of 200ms
but not with slowdowsn of 50ms

State of the Art Data Point: A google search for "state of art
performance testing" from a slow broadband (ADSL 1.5MB/s) IE7 client
in Dulles VA has an average response time of 861 ms (entire page)

The State of the practice
The web is slow, unnecessarily slow, sometimes painfully slow.
Most website owners (and most developers)
dont know that their websites are slow,
and they dont know how to fix them

Above Average Data Point: If you search either meetup.com or LinkedIn
for "performance testing"
from same client as above both have an average response time of 2.0
sec (entire page).

Sources
Designing and Engineering Time by Steven Seow
papers from Xerox Parc
The O'Reilly Velocity Conference proceedings for 2007 to 2009
My clients
Remote test tools like Keynote, Neustar, Gomez etc

Worth noting again that for any long-running code or benchmarks,
you'll want to pass --server to use the optimizing JVM in JRuby. Much
faster.

On Wed, Aug 19, 2009 at 9:36 PM, <> wrote:
> On Wed, Aug 19, 2009 at 5:05 PM, Charles Oliver
> Nutter<> wrote:
>> On Wed, Aug 19, 2009 at 8:31 AM, Ben
>> Christensen<> wrote:
>>> I've started down a path of doing various performance tests to see what
>>> kind of impact will occur by using Ruby and in my first test the numbers
>>> are very poor - so poor that I have to question if I'm doing something
>>> wrong.
>>
>> 1.8.6 is pretty slow, compared to other impls. Ruby 1.9 and JRuby will
>> perform better, as shown by a few folks. JRuby on a Java 6 JVM with
>> --fast and --server should perform very well.
>
> And, of course JRuby adds other possibilities:
>
> $ java FileReadParse
> Starting to read file...
> The number of tokens is: 234937
> It took 2098 ms
>
> $ java FileReadParse
> Starting to read file...
> The number of tokens is: 234937
> It took 788 ms
>
> $ ruby -v file_read_parse.rb
> ruby 1.8.2 (2004-12-25) [powerpc-darwin8.0]
> Starting to read file ...
> The number of tokens is: 234937
> It took 2666.646 ms
>
> $ jruby -v file_read_parse.rb
> jruby 1.3.1 (ruby 1.8.6p287) (2009-06-15 2fd6c3d) (Java HotSpot(TM)
> Client VM 1.5.0_16) [ppc-java]
> Starting to read file ...
> The number of tokens is: 234937
> It took 3120.0 ms
>
> $ jruby --fast --server -v file_read_parse.rb
> jruby 1.3.1 (ruby 1.8.6p287) (2009-06-15 2fd6c3d) (Java HotSpot(TM)
> Client VM 1.5.0_16) [ppc-java]
> Starting to read file ...
> The number of tokens is: 234937
> It took 2809.0 ms
>
> $ jruby -v file_read_parse-2.rb
> jruby 1.3.1 (ruby 1.8.6p287) (2009-06-15 2fd6c3d) (Java HotSpot(TM)
> Client VM 1.5.0_16) [ppc-java]
> Starting to read file...
> The number of tokens is: 234937
> It took 593 ms
>
> $ java FileReadParse
> Starting to read file...
> The number of tokens is: 234937
> It took 588 ms
>
> $ jruby -v file_read_parse-2.rb
> jruby 1.3.1 (ruby 1.8.6p287) (2009-06-15 2fd6c3d) (Java HotSpot(TM)
> Client VM 1.5.0_16) [ppc-java]
> Starting to read file...
> The number of tokens is: 234937
> It took 595 ms
>
> $ cat file_read_parse-2.rb
> require 'java'
> java_import 'FileReadParse'
>
> FileReadParse.new.do_stuff
>
>
>
>