Is ruby's regex slower?

[Jeff Peng]

Kirk Haines:

How about this:

A dynamic web site that's been running a couple years, with all of the
content pulled from a database, and navigation generated dynamically
from db contents, running on a shared server that is a few years old
(i.e. not cutting edge hardware), running on Ruby 1.8.6 (i.e. not a
speedy version of Ruby).

Requests per second: 137.45 [#/sec] (mean)

Make it more complex by pulling a page that renders a big table of
itty bitty numbers for mutual fund performance:

Requests per second: 82.48 [#/sec] (mean)

However, mitigate even those slow speeds by running it behind a load
balancer, implemented with Ruby, that caches the generated pages and
serves them from cache (while the LB is also managing requests for 70
other sites):

Requests per second: 6107.65 [#/sec] (mean)

Those show the statistics for a small application IMO.
Once our application serves 200 million page views each day, and
generates 4T datas on storage. Under that case, the languange is really
sensitive, so we go with C/C++.

Regards,
Jeff.

 

[Kirk Haines]

Those show the statistics for a small application IMO.

Sure.

Once our application serves 200 million page views each day, and generates
4T datas on storage. Under that case, the languange is really sensitive, so
we go with C/C++.

*shrug*

Data storage is irrelevant, since that's all carried by whatever
technology one is using for the data store -- there are no Ruby
performance implications there.

200,000,000 page views a day, though.... So what? Architect the
_application_ right, and the scaling will follow (though sometimes
getting that architecture right is a bitch). The devil is in the
details. I can say with confidence, though, that I could spin up an
Engine Yard Cloud instance tomorrow, duplicate this app I referenced
onto it, and using a 100% Ruby stack (i.e. without even using the EY
default nginx for front end web server), I am confident that I could
drive 200,000,000 page views through it in a day on a single instance.

However, it's not a pissing contest. Someone can always come up with
instances where more speed is absolutely vital, requiring one to make
specific language choices to realize the needed speed. Nor am I
saying that we shouldn't be thinking about performance when working on
the internals of MRI or any other Ruby implementation; we should! But
the assertion that I was responding to -- that Ruby's performance (MRI
Ruby's anyway) is somehow inadequate for delivering very fast web
applications -- is clearly false.

To come around to the original line of inquiry, though... People are
on the right track by looking at the Ruby 1.9 performance. One might
also look at Rubinius and JRuby. However, the method of timing is
suspect. Timings should be taken from _inside_ the code, wrapped
around the specific items being timed, so that one eliminates
differences in startup costs in the final numbers. One should also,
if looking at jruby, collect timings from multiple iterations so that
the optimizer has a chance to do its thing.


Kirk Haines

 

[Robert Klemme]

Why does everybody say that CPUs are fast nowadays and that "it dosn't
mattar that language XYZ is slow"?

Dunno about everybody else. I did not

a) say that CPU's are fast nowadays,
b) say that it does not matter that Ruby is slow,
c) claim we should not care about Ruby's performance.

I specifically asked "does it matter?" For me it doesn't (especially
since 1.9 is there) but that does not mean that it doesn't for others.
Hence the question.

It does matter: web applications. If your applications can't serve all
the visitors, then you're going to lose your customer or you'll have to
learn some other language with better performance.

Kirk has responded better than I could and I believe there is nothing
more I could add to this.

Kind regards

robert

 

[Phillip Gawlowski]

Why does everybody say that CPUs are fast nowadays and that "it dosn't
mattar that language XYZ is slow"?

I have a Core2Dual, with each core clocking in at 2GHz. This is a
low-end CPU. Do you think I'm bothered about a millisecond, or even
100ms, for that matter?

The speed of an application isn't just in the language used, but in how
fast an application appears. If it seems that an application is fast by,
for example, starting to display data soon enough (in a CRUD app,
starting to show the first few rows of the result set, while the
backend's still collecting the whole shebang), is for all intents and
purposes fast enough.

It does matter: web applications. If your applications can't serve all
the visitors, then you're going to lose your customer or you'll have to
learn some other language with better performance.

Especially in web applications, the speed of your language of choice is
less relevant than in any other possible scenario. You have about 2
seconds per unique visitor to build the whole page, before users think a
website is slow. That's ages.

Now, if we talk about mobile devices, then CPU and memory constraints
start to reappear. But not on the desktop and the intertubes.

 

[Charles Oliver Nutter]

But my point was a bit different. =C2=A0Python and Ruby are basically sim= ilar
languages, and what annoys me is that there seems not to have been the
will in the Ruby community to steal some speed tricks from Python. =C2=A0= (I'd
be working on this if I knew anything practical about language
implementation, but I don't.)

Unfortunately, the Python community seems to turn to "write it in C" a
lot more often than the Ruby community has, so the #1 performance
trick for Python is to not write in Python. That's obviously the wrong
direction for us to go...I don't think anyone here would prefer to
write C over Ruby (or Java, or C++, or C#) when Ruby is the right tool
for the job...

And I'll also mention the truth of performance we've discovered
repeatedly in JRuby: if you don't have fast core classes, you don't
have a fast Ruby implementation. 99% of the performance problems we've
investigated over the years could be traced back to core class
implementations, which in most implementations are already written in
a "fast" language like C or Java (Rubinius has a mix of C++ and Ruby
for most core classes, with emphasis on Ruby). So a large number of
poor-performing systems in Ruby can be directly attributed to misuse
or slow implementation of core methods. And that's a much harder and
extensive challenge to meet.

- Charlie

 

[Phrogz]

Kirk Haines:

Requests per second:    6107.65 [#/sec] (mean)

Those show the statistics for a small application IMO.
Once our application serves 200 million page views each day

200 million page views a day is an average of 2,300 page views a
second. This is reasonably close under the statistic that Kirk cited
(for some conversion between page views and requests).

 

[Marnen Laibow-Koser]

Unfortunately, the Python community seems to turn to "write it in C" a
lot more often than the Ruby community has, so the #1 performance
trick for Python is to not write in Python. That's obviously the wrong
direction for us to go...I don't think anyone here would prefer to
write C over Ruby (or Java, or C++, or C#) when Ruby is the right tool
for the job...

Devil's advocate: *is* Ruby the right tool the job for thoses cases?
Obviously, I'd rather write in Ruby than in C* or Java, but in a case
where the use of Ruby leads to performance problems, Ruby is probably
ipso facto not the right tool for the job.

And I'll also mention the truth of performance we've discovered
repeatedly in JRuby: if you don't have fast core classes, you don't
have a fast Ruby implementation. 99% of the performance problems we've
investigated over the years could be traced back to core class
implementations, which in most implementations are already written in
a "fast" language like C or Java (Rubinius has a mix of C++ and Ruby
for most core classes, with emphasis on Ruby). So a large number of
poor-performing systems in Ruby can be directly attributed to misuse
or slow implementation of core methods. And that's a much harder and
extensive challenge to meet.

I can well believe that, though I had understood that some of Python's
speed boost came from bytecode compilation as well.

- Charlie

Best,
-- 
Marnen Laibow-Koser
http://www.marnen.org
(e-mail address removed)

 

[Robert Klemme]

Devil's advocate: *is* Ruby the right tool the job for thoses cases?
Obviously, I'd rather write in Ruby than in C* or Java, but in a case
where the use of Ruby leads to performance problems, Ruby is probably
ipso facto not the right tool for the job.

Before you can make that judgement you need to find out the reason for
slowness. A flawed design might be faster in C but fixing the design in
Ruby might yield even better performance.

I can well believe that, though I had understood that some of Python's
speed boost came from bytecode compilation as well.

http://en.wikipedia.org/wiki/YARV

robert

 

[Jeff Peng]

Robert Klemme:

Before you can make that judgement you need to find out the reason for
slowness. A flawed design might be faster in C but fixing the design in
Ruby might yield even better performance.

I have sounded many guys talking about the flawed design when they
compare a languange to another. Yes a flowed design will make program
run much slower even it's by C. But the problem is, if a person make bad
desigin in C language, will he do it right in other language like Ruby?
I very doubt it.

 

[Robert Klemme]

Robert Klemme:


I have sounded many guys talking about the flawed design when they
compare a languange to another. Yes a flowed design will make program
run much slower even it's by C. But the problem is, if a person make bad
desigin in C language, will he do it right in other language like Ruby?
I very doubt it.

I'm sorry, I really don't understand how your reply relates to my
statement. I responded to Marnen questioning whether Ruby was the right
tool for a particular job. I wasn't talking about the language's design
but about the design of the application. And I specifically suggested
to fix the design but keep the language and not fix the design in a
different language. Of course, if the design isn't flawed or the person
doing the fix can't do it (in either language) then the whole procedure
is deemed to fail.

Kind regards

robert

 

[Roger Pack]

You could try ruby 1.9 and see if it helps the speed.

You could also try
jruby --fast [+= --1.9]
-r

 

[Jose Hales-Garcia]

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

I have sounded many guys talking about the flawed design when they
compare a languange to another. Yes a flowed design will make
program run much slower even it's by C. But the problem is, if a
person make bad desigin in C language, will he do it right in other
language like Ruby? I very doubt it.

Someone once said: "It's a poor workman who blames his tools." How
true it is.

Jose
.......................................................
Jose Hales-Garcia
UCLA Department of Statistics
(e-mail address removed)

 

[Charles Oliver Nutter]

You could also try
jruby --fast [+= --1.9]

And --server, and as recent a JVM version as you can get

- Charlie