Is ruby's regex slower?

ruby-talk
21

That's such a red herring that I'm not even sure how to address it.

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)

Sure, performance improvements in the language implementations are
great -- it's always good when our stuff runs faster. But it's absurd
to argue that Ruby, even in the older versions of MRI, can't provide
far more than sufficient performance for _really_ fast web
applications. I made my living writing web software with Ruby for
several years before most anyone else was doing it, and even then, in
that particular application arena, Ruby always proved to be more than
fast enough to render complex web pages in a few milliseconds.

And these days, the landscape is nowhere near that simple. Look at
Ruby 1.9.x, or JRuby, or Rubinius, and see where the trends are
heading. The future looks good, IMHO.

Kirk Haines

···

On Tue, Jan 5, 2010 at 9:47 PM, Albert Schlef <albertschlef@gmail.com> wrote:

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

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.

22

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.

···

On 06.01.2010 05:47, Albert Schlef wrote:

--
Phillip Gawlowski

23

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

···

On Tue, Jan 5, 2010 at 10:32 AM, Marnen Laibow-Koser <marnen@marnen.org> wrote:

But my point was a bit different. Python and Ruby are basically similar
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. (I'd
be working on this if I knew anything practical about language
implementation, but I don't.)

24

Well, 1.9 *has been* improved dramatically in the area of performance (among others). Whether this is because of "tricks stolen from Python" I cannot judge. Your statement seems to imply that the Ruby community is negligent of performance which is not true.

Kind regards

  robert

···

On 01/05/2010 05:32 PM, Marnen Laibow-Koser wrote:

But my point was a bit different. Python and Ruby are basically similar 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. (I'd be working on this if I knew anything practical about language implementation, but I don't.)

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

25

Robert Klemme wrote:

Yeah. I love Ruby, but I'm getting a bit annoyed by the fact that it's so much slower than Python...

The question is: does it matter for most practical purposes - and: do
you want to sacrifice a clean and simple program and the fun of creating
it for a few cycles of CPU time? I wouldn't - especially since 1.9 is
so much faster than 1.8 was. My 0.02EUR.

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

···

On 01/06/2010 05:47 AM, Albert Schlef wrote:

On 01/05/2010 12:37 PM, Marnen Laibow-Koser wrote:

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

26

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.

27

Charles Nutter wrote:

But my point was a bit different. Python and Ruby are basically similar
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. (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...

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,

···

On Tue, Jan 5, 2010 at 10:32 AM, Marnen Laibow-Koser <marnen@marnen.org> > wrote:

--
Marnen Laibow-Koser
http://www.marnen.org
marnen@marnen.org
--
Posted via http://www.ruby-forum.com/\.

28

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

29

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).

···

On Jan 5, 10:44 pm, Jeff Peng <jeffp...@netzero.net> wrote:

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

30

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.

  robert

···

On 01/06/2010 06:27 PM, Marnen Laibow-Koser wrote:

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

31

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.

32

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

···

On 01/07/2010 11:02 AM, Jeff Peng wrote:

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.

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

33

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

Jose
.......................................................
Jose Hales-Garcia
UCLA Department of Statistics
jose@stat.ucla.edu

···

On Jan 7, 2010, at 2:02 AM, Jeff Peng wrote:

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.