Ruby is slow? - some experience

[lastcraft]

Hi.

Just been porting some PHP/Perl code to ruby and timing the results. I have found slap dash ruby code to be an order of magnitude slower than slap dash PHP code. All those little blocks reading files rather than File.readlines hurts badly, whereas the PHP file() and array_map() functions are very natural. PHP arrays are blindingly fast and I have a new found respect for them (although they suck up memory).

With a bit of optimisation things changed. I/O is roughly comparible, maybe a bit slower in ruby. Unfortunately there is no equivalent of file_put_contents(), but I was mainly reading.

Ruby hashes are about the same as PHP hashes. PHP hashes preserve ordering though, which can save you a lot of processing later.

Ruby arrays seem to be about 3-5 times slower than PHP when looping through. Even the Array.collect {} syntax is a lot slower than array_map().

Ruby string concatenation is much slower. I don't have a multiple, but the profiled PHP code didn't show it as even being an issue, where as it came to 20% odd of the processing in Ruby.

I was doing real world stuff here with big data sets, manipulating about 200meg of data in memory. In PHP you have to set the memory limit and timeout of course, which is an irritation. My gut feel though is that the ruby code comes out 1.5 times slower after an hour of optimisation. The optimisation had a big impact on the ruby code, but I could not really get PHP to go any quicker.

The problem space was a lot of string, hash and file manipulation. It was much faster to write the Ruby code, but I wrote it the second time around in ruby so I think that was the real reason. For me there is currently little difference in productivity.

Anyways, any other people getting the same experiences?

yours, Marcus

[Sgarissta]

Hi.

Just been porting some PHP/Perl code to ruby and timing the results. I have found slap dash ruby code to be an order of magnitude slower than slap dash PHP code. All those little blocks reading files rather than File.readlines hurts badly, whereas the PHP file() and array_map() functions are very natural. PHP arrays are blindingly fast and I have a new found respect for them (although they suck up memory).

With a bit of optimisation things changed. I/O is roughly comparible, maybe a bit slower in ruby. Unfortunately there is no equivalent of file_put_contents(), but I was mainly reading.

Actually based on the way Ruby's IO works, you can just do something as simple as

File.open (stuff here) { |f|
   f << YourDataArray.join('\n')
}

Ruby hashes are about the same as PHP hashes. PHP hashes preserve ordering though, which can save you a lot of processing later.

Ruby arrays seem to be about 3-5 times slower than PHP when looping through. Even the Array.collect {} syntax is a lot slower than array_map().

Ruby string concatenation is much slower. I don't have a multiple, but the profiled PHP code didn't show it as even being an issue, where as it came to 20% odd of the processing in Ruby.

Try using the << operator for concatenation, it doesn't create new string objects during the addition, and is typically much faster.

I was doing real world stuff here with big data sets, manipulating about 200meg of data in memory. In PHP you have to set the memory limit and timeout of course, which is an irritation. My gut feel though is that the ruby code comes out 1.5 times slower after an hour of optimisation. The optimisation had a big impact on the ruby code, but I could not really get PHP to go any quicker.

The problem space was a lot of string, hash and file manipulation. It was much faster to write the Ruby code, but I wrote it the second time around in ruby so I think that was the real reason. For me there is currently little difference in productivity.

Anyways, any other people getting the same experiences?

Yes. Ruby is typically a slower than PHP and Perl for heavy text processing, just do to the object overhead but once you've adjusted to "The Ruby Way" you'll find one-off processing scripts are much faster to write in Ruby, and only marginally slower.

[bonefry]

Well, with the risk of repeating another post of mine on another thread:
Ruby's interpretter SUCKS -> it's the worst I've ever seen, let's hope Ruby 2.0 which prommises better performance is revealed soon enough.
Python is also object oriented and it's faster (as fast as PHP). So there is hope.

[bonefry]

http://shootout.alioth.debian.org/be...y&sort=fullcpu
the difference between Perl and Ruby aren't that high (aprox 4x)

http://shootout.alioth.debian.org/be...p&sort=fullcpu
that's PHP that is still slower than Perl (a bytecode engine will surelly fix this)

http://shootout.alioth.debian.org/be...n&sort=fullcpu
and Python apparently is head to head with Perl

So, if Python can do it, so will Ruby. Problem is Ruby is very new (in the rest of the world outside Japan at least)

[Sgarissta]

Well, with the risk of repeating another post of mine on another thread:
Ruby's interpretter SUCKS -> it's the worst I've ever seen, let's hope Ruby 2.0 which prommises better performance is revealed soon enough.
Python is also object oriented and it's faster (as fast as PHP). So there is hope.

To compare Python's OO to Ruby's is hardly close. Ruby's OO is much closer to Smalltalk (everything's an object, everything is routed to sending messages between objects) where as in Python everything is a method call, and it's OOP is an addon, which becomes obvious from passing self everywhere. That doesn't negate the fact that Ruby is slow, but that's as much because the Ruby 'motto' (whether you agree with it or not) so to speak has been Ruby is fast enough for most tasks, and when its not, you can recode the hotspots in C.

[Sgarissta]

http://shootout.alioth.debian.org/be...y&sort=fullcpu
the difference between Perl and Ruby aren't that high (aprox 4x)

http://shootout.alioth.debian.org/be...p&sort=fullcpu
that's PHP that is still slower than Perl (a bytecode engine will surelly fix this)

http://shootout.alioth.debian.org/be...n&sort=fullcpu
and Python apparently is head to head with Perl

So, if Python can do it, so will Ruby. Problem is Ruby is very new (in the rest of the world outside Japan at least)

I'm not exactly sure what Ruby's age has to do with it's speed. There is also a long running debate in the Ruby community about how valid the alioth benchmarks are for Ruby so I'd take the benchmarks with a grain of salt. Again, I'm not debating the fact that Ruby is indeed slower than most interpreted languages for some tasks that much is obvious.

[KTottE]

Perl is version 5.8, PHP is version 5.x, Python (the latest branch anyway) is 2.4.x.

Ruby is only at 1.8.x.

I think this accounts for most of the performance issues, the Ruby interpreter has up until now focused on creating a Good Language and a Stable Environment. Now with version 2 they are focusing on Fast Execution.

[bonefry]

Perl is version 5.8, PHP is version 5.x, Python (the latest branch anyway) is 2.4.x.

Ruby is only at 1.8.x.

It really doesn't matter when comparing versions because you don't know they have the same standards in versioning.

Example: until PHP 3, PHP was a joke, so I think it's crystal clear that 1.8.3 in Ruby vs 5.x in PHP vs 5.8 in Perl doesn't mean sh*it

...so I'd take the benchmarks with a grain of salt...

Yes, Ruby could indeed be slower in reality Just kidding (or not?)

To compare Python's OO to Ruby's is hardly close. Ruby's OO is much closer to Smalltalk (everything's an object, everything is routed to sending messages between objects) where as in Python everything is a method call, and it's OOP is an addon, which becomes obvious from passing self everywhere.

That's F-U-D. And I don't like FUD.
I know Python and I can testify that Python is OOP. And in Python "EVERYTHING IS AN OBJECT" too
There are differences in phylosophies though. Ruby has indeed the concept of message passing inheritted from Smaltalk while in Python there is a clear difference between properties and methods because the "method" is still a central construct. But it only depends on what you find as being OOP i.e. are you sure "message passing" is the only way ?
Also a good language is a language that can evolve over time. Python has indeed evolved to be "completelly OOP", but are you sure Ruby will evolve in the future as beautifull as Python did until now ? Because ideeas and phylosophies change, and evolutions and sometimes revolutions are required.
Python is a wonderfull language too, so please don't post any more FUDs and flame-baits.
PS: I quite like "self" so it's only a matter of taste.

[Sgarissta]

That's F-U-D. And I don't like FUD.
I know Python and I can testify that Python is OOP. And in Python "EVERYTHING IS AN OBJECT" too
There are differences in phylosophies though. Ruby has indeed the concept of message passing inheritted from Smaltalk while in Python there is a clear difference between properties and methods because the "method" is still a central construct. But it only depends on what you find as being OOP i.e. are you sure "message passing" is the only way ?

I don't think I claimed it was "the only way" just that it was the way Ruby did it, and is in fact part of the reason for its performance issues.

Also a good language is a language that can evolve over time. Python has indeed evolved to be "completelly OOP", but are you sure Ruby will evolve in the future as beautifull as Python did until now ? Because ideeas and phylosophies change, and evolutions and sometimes revolutions are required.
Python is a wonderfull language too, so please don't post any more FUDs and flame-baits.

Sorry you saw my comments as FUD or flame-bait, I was simply making a statement regarding the different design philosophies of the languages, and how it relates to their performance. Please try to keep this on the topic of performance, if you want to do a down and dirty comparison of Ruby and Python, feel free to start another thread.

[bonefry]

I don't think I claimed it was "the only way" just that it was the way Ruby did it, and is in fact part of the reason for its performance issues.

Sorry you saw my comments as FUD or flame-bait, I was simply making a statement regarding the different design philosophies of the languages, and how it relates to their performance. Please try to keep this on the topic of performance, if you want to do a down and dirty comparison of Ruby and Python, feel free to start another thread.

OK, I must have missunderstood you (although you missunderstand Python too).

And no, there shouldn't be any performance penalties for Ruby because it has a more pronounced message passing philosophy.

Ruby behaves exactly the same as Python when accessing methods or properties. The only thing that's different is that in Python the method itself is an object and in Ruby the method can be wrapped inside an object (Proc). And that's a huge difference in philosophy. But when actually calling a method on an object, there is no difference. The same message passing technique applies to both since they are both dynamic.

That is why there shouldn't be any difference between Python and Ruby in performance just because Ruby is OOP. And that's why Ruby can be at least as fast as Python.

Off Topic:

A note about the self parameter: it is still available in recent versions because it is pythonic to have access to all inner workings. For example, in python, you don't have private variables, you only have a way to hide them from the class dictionary, but nothing else prevents you from accessing it. It is just pythonic not to hide stuff like that. In few words: "Easy to use, but visible". It is only a matter of taste, as I said.

[Sgarissta]

OK, I must have missunderstood you (although you missunderstand Python too).

And no, there shouldn't be any performance penalties for Ruby because it has a more pronounced message passing philosophy.

Ruby behaves exactly the same as Python when accessing methods or properties. The only thing that's different is that in Python the method itself is an object and in Ruby the method can be wrapped inside an object (Proc). And that's a huge difference in philosophy. But when actually calling a method on an object, there is no difference. The same message passing technique applies to both since they are both dynamic.

Just to clarify for my own knowledge here...So python method calls on an object are really just wrappers for calling a generic "send" method for that object? Can you do the method_missing functionality from ruby, where if you call a method (or request a property) that doesn't exist on the object, you can catch it, and route it to something else?

That is why there shouldn't be any difference between Python and Ruby in performance just because Ruby is OOP. And that's why Ruby can be at least as fast as Python.

No doubt Ruby can be faster, in theory it should be able to approach smalltalk in terms of speed.

[bonefry]

Just to clarify for my own knowledge here...So python method calls on an object are really just wrappers for calling a generic "send" method for that object?

Well, no, in Python the class works more like a namespace. So when you do something like obj.execMethod() you really are directly accessing the method, not just a wrapper. And obj.execMethod is a reference to the method, so you can do:

f = obj.execMethod
f()

Notice the difference from Ruby. But if execMethod is missing, you can track that call and execute another function or throw exceptions or something, just like in Ruby.

Can you do the method_missing functionality from ruby, where if you call a method (or request a property) that doesn't exist on the object, you can catch it, and route it to something else?

Yes, you can do that in Python with both properties and methods.

[Dr Livingston]

Honestly folks, I've just got to laugh... All this steam about Ruby being the best thing since sliced cheese, etc etc etc.

And it's slow...

Python is also object oriented and it's faster (as fast as PHP). So there is hope.

Well, after reading this thread, I'm kind of glad I followed my gut instinct to learn Python. The option of learn Ruby has always been there of course, but for some reason (gut instinct maybe) I've never felt at ease about Ruby.

I still don't, even if there was to be an inprovement on performance. Ruby is said by many on these forums that it is a lot more flexible, etc. Well, for that flexibility, there is also a penalty I suppose.

It's ironic to read someone say that there is hope, in the context of being compared to something like Python. I've always had the vision that Python was the better language of the two anyways, but reading this just goes and confirms it.

Ruby doesn't rock people. It never has, and I'm sorry if this comes across as being negative, but I'm being honest if nothing else.

[Luke Redpath]

Why is everybody getting hung up on speed? Hardware is cheap, programmers aren't.

Seriously, as has been said many times, if we were all hung up about speed, surely we'd be writing everything in C?

[joflow]

Ruby is only on version 1.x

Was PHP as fast as it is now when it was on version 1.x?

[vgarcia]

Was PHP as fast as it is now when it was on version 1.x?

PHP was a total joke until about version 4.

[joflow]

PHP was a total joke until about version 4.

I figured as much.

So I think anyone writing Ruby off before it atleast has time to mature is probably doing themselves a great disservice.

[vgarcia]

I figured as much.

So I think anyone writing Ruby off before it atleast has time to mature is probably doing themselves a great disservice.

Truth be told, you can't tell much about software by its version number. Case in point: Mac OSX. They release "point updates" every year, but you'd be hard-pressed to tell someone that knows anything about the OS that not much has changed between version 10.0 and 10.4. Conversely, just look at the companies that love skipping version numbers, like Macromedia and Netscape. Look at software on its technical merits, not how many releases they've had.

[Luke Redpath]

No offence, but your reasoning on the version number is a bit off - like bonefry said in the other thread, the versioning schemes are not comparable. Ruby might be 1.8.2, but has been around for a decade. Its had plenty of time to mature, and as a language, it has.

As has been stated, the problem generally lies with the interpreter, not the language, and I believe this is a target for 2.0.

Also, PHP started life as nothing more than a template language for Perl, so again, hardly a fair comparison either way.

[Sgarissta]

Honestly folks, I've just got to laugh... All this steam about Ruby being the best thing since sliced cheese, etc etc etc.

And it's slow...



Well, after reading this thread, I'm kind of glad I followed my gut instinct to learn Python. The option of learn Ruby has always been there of course, but for some reason (gut instinct maybe) I've never felt at ease about Ruby.

I still don't, even if there was to be an inprovement on performance. Ruby is said by many on these forums that it is a lot more flexible, etc. Well, for that flexibility, there is also a penalty I suppose.

It's ironic to read someone say that there is hope, in the context of being compared to something like Python. I've always had the vision that Python was the better language of the two anyways, but reading this just goes and confirms it.

Ruby doesn't rock people. It never has, and I'm sorry if this comes across as being negative, but I'm being honest if nothing else.

I'm glad you've enjoyed yourself. You often have a lot of insight on the Advanced PHP Forum, but this is an outright childish attack, and reaks of jealousy at "not getting it". Fine, here's a subject attack about on par with what you've just posted, enjoy.

Do you feel like a better person for letting us all know this? Honestly I couldn't give a crap about your opinion on a language you haven't used, "gut feeling" or not, sorry if that comes across as negative, I'm just being honest. I LIKE the way Ruby code comes out, I like the way Ruby code "feels". I LIKE the flexibility of Ruby. Please, if you don't care about Ruby at all (which you seem to keep saying, who are you trying to convince?), get the hell out of of the Ruby forum.

I'll freely admit Ruby is slower than its competition in many ways, but I don't care. If it was all about speed, we'd all still be writing hand-crafted assembly.

Have fun ripping on other people's choices!

[lastcraft]

Hi...

Why is everybody getting hung up on speed? Hardware is cheap, programmers aren't.

True, but the task I was performing was a twenty minute run with human judgment at the beginning and end. Having that ten times slower is significant enough that optimisation time (a day) was set aside. I am quite happy to have got the all-Ruby version within a factor of two of the Perl/PHP/Bash salad that existed before.

The caveat is that Ruby does require some sacrifice of developer time in optimisation for long jobs, as unoptimised it can end up a total dog. That has to be subtracted from a possibly faster development speed for the initial prototype.

Thanks for the IO tips (again). They seem to make a marginal, but measurable, difference. Unfortuanately I have ripped out all of the timing statements I put in, so I cannot give any figures now.

I like this forum already .

yours, Marcus

[joflow]

No offence, but your reasoning on the version number is a bit off - like bonefry said in the other thread, the versioning schemes are not comparable. Ruby might be 1.8.2, but has been around for a decade. Its had plenty of time to mature, and as a language, it has.

As has been stated, the problem generally lies with the interpreter, not the language, and I believe this is a target for 2.0.

Also, PHP started life as nothing more than a template language for Perl, so again, hardly a fair comparison either way.

Interesting...I thought Ruby was relatively new.

Since its been around for 10 years...does this mean that development has been slow (if this is the case, maybe development will pick up now that there is alot of interest in Ruby)? If this is the case then it there would be hope that future versions will be faster but if Ruby has gone through steady development for 10 years and is still slow then I'd now have to side with Dr. Livingston in saying that Ruby pretty much sucks.

[Luke Redpath]

Hi Marcus

My post should have included a quote really as out of context I guess its sounds like an attack at this thread in general. It wasn't, and wasn't suggested that you were getting "bothered" by the speed either. I was more bothered by Dr Livingstone's seeminly pointless post about why Ruby's speed could firmly tick another box in his "Why Python is better" list, and others who were getting hung up over the issue.

[Luke Redpath]

Interesting...I thought Ruby was relatively new.

Since its been around for 10 years...does this mean that development has been slow (if this is the case, maybe development will pick up now that there is alot of interest in Ruby)? If this is the case then it there would be hope that future versions will be faster but if Ruby has gone through steady development for 10 years and is still slow then I'd now have to side with Dr. Livingston in saying that Ruby pretty much sucks.

The reason is that development has concentrated on the language, not optimisation.

If you don't really use Ruby and have come to the (rather worthless) conclusion that it sucks because of its speed, despite its many positives, then I guess you don't really have much else to contribute do you? Ruby is generally fast enough for most uses. This doesn't mean that it shouldn't be optimised, or could do with a better interpreter, nor should it mean you don't use it just because there are faster languages.

Do some people seriously have nothing better to do than come here to bash Ruby? Can we please have a bit of moderation in this forum? Go and troll elsewhere.

[joflow]

Well then I guess there is hope of speed improvements then.

I'm not really bashing ruby...I've never used it personally. I'm in the process of setting up a site with ruby as a trial run and I'll begin development as soon as I find some good tutorials on rails (seems hard to find good resources on the framework).

But every forum I've been too seems to have at some complaints about the speed so I assumed it was a huge problem. I'll hold off further judgement until I've tested it out myself and see if its fast enough for my needs.