so far, all the answers i get is "they are roughly the same performance wise. resource wise. speed wise"

ok. the thing is. i want a definite answer. even if ruby is 0.0000000000000000000000001% faster than php, i would appreciate a straightforward "ruby is faster" answer.

i've search the web and can't find any php vs ruby on rails resource/speed comparison benchmarks.

It's really hard to compare. They do things differently. Rails has more overhead because it's an entire framework.

On top of that setting up the server in rails is a lot more complicated as most people end up using lighthttpd instead of apache. The answer is it depends entirely too much. If you want to know for YOUR situtaion...test it on your hardware/software/application

ok. i've got the answer from the creator himself.

ruby on rails takes more resources and is slower than php.

http://www.loudthinking.com/arc/000479.html

he is arguing that productivity cost is higher than server cost though, which is true.

There's always the good 'ol language shootout page: here (http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=php&lang2=ruby) and here (http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=php&lang2=ruby) which seems to indicate that Ruby performs much better at most things (which is what I'd expect), however Rails will add some significant overhead, and I doubt anyone's seriously benchmarked it. For most intents and purposes the performance of the language is irrelevant; issues such as development cost and algorithm choice are much more important.

are frameworks slower than non-frameworks?

are frameworks slower than non-frameworks?

It's a tradeoff. The frameworks have more overhead to get going and require more resourced to run, but they make building applications much more consistant and expandable than a bunch of procedural code.

Okay, maybe the reason you haven't seen any comparisons between RoR and PHP is because they are not the same thing.

PHP is a language. It is not a framework built on top of a language which is what RoR is. If you want a direct comparison, compare PHP - the language, with Ruby, the language.

Even then, you cannot find a decent comparison because unlike Ruby (which is a gp programming language), PHP is specifically designed for web development.

I suspect the author of RoR put up those benchmarks because a lot of people make the wrong assuming that RoR is a replacement for PHP. If you want to compare RoR, compare it with other PHP-based frameworks (and there are tons of them).

Comparing one language against another is incorrect. Even if you benchmark two implementations of the same algo in two languages - you're comparing two different programs, not the same program but in different language.

ok. i've got the answer from the creator himself.

ruby on rails takes more resources and is slower than php.

http://www.loudthinking.com/arc/000479.html

he is arguing that productivity cost is higher than server cost though, which is true.
Actually until you hit CPU performance bottleneck (which is let's say like 30 hits per second for RoR) - there's no difference. And that's roughly 1.2 million page views daily. At that number of page views usually one can afford to spend extra couple hundred dollars monthly on hardware.

Comparing one language against another is incorrect. Even if you benchmark two implementations of the same algo in two languages - you're comparing two different programs, not the same program but in different language.

Are you suggesting you can't benckmark languages against themselves? If so this seems a bit silly...they are the "same program" in that they are doing the same thing. So long as the implementations of the algorithm don't take advantaged of a weakness of one of the languages then the comparison works just fine.

I mean that every real-world program that is at least a bit more complex than simple "Hello World" should use optimizations specific for language and/or language implementation.

If so this seems a bit silly...they are the "same program" in that they are doing the same thing.
There are usually lots of ways you can "do the same thing" even in one language. And you'll get different performance. And even if program code looks the same in two languages (if you change only syntax to fit another language), underlying implementation may do completely different things. Good example is string concatenation - in some languages it's ok to do things $var .= "..." throughout your program (in long loops etc.), then output contents of the variable, but in other languages this will be a performance-killer.

And even if program code looks the same in two languages (if you change only syntax to fit another language), underlying implementation may do completely different things.

When doing benchmarks you never merely "translate" one implementation into the other (unless you're intentionally creating a biased benchmark...), rather you take a good implementation of the algorithm in one language and a good implementation in the other both as I said previously "should not take advantage of a weakness...". In other words you can make reasonable comparisons between an algorithm written in two different languages so long as it wasn't implemented in an idiotic matter in either language. This sort of thing is done all the time, as surely some people really do care about performance and base their language choice on it. Although if the two languages have different domains they were built around this can make a comparison a bit more difficult.

Also I've yet to experience an example where a major improvement occured while changing the implementation of an algorithm. Its always a theoretical change in the algorithm that causes big improvements.

Its always a theoretical change in the algorithm that causes big improvements.

This and better hardware support for that type of algorithm (I'm talking about registers here, op codes etc, not more RAM and such things)

That's true for mathematical benchmarks or some other kinds of microbenchmarking. What's more interesting is language/implementation performance on typical web tasks. And typical web "algorithm" looks like:
1) parse user request
2) fetch some data from database backend, probably update some data there
3) feed that data to template engine
4) transfer output from template engine to client
Sounds pretty simple, but there's multitude of ways coding it even with one language - some are slower, some are faster.

This and better hardware support for that type of algorithm (I'm talking about registers here, op codes etc, not more RAM and such things)

Well in some sense yes there is "exotic" hardware out there that can do particular things very well. But on typical "PC" hardware there isn't that much difference.

And typical web "algorithm" looks like:
1) parse user request
2) fetch some data from database backend, probably update some data there
3) feed that data to template engine
4) transfer output from template engine to client

This isn't really what I had in mind when I saw the word "algorithm", I would call that an web architecture not an "algorithm". What I hand in mind was what the word refers to in computer science. For example an algorithm for sorting data or an algorithm for data mining.

So then in the example you gave you'd be benchmarking frameworks against each other. But these benchmarks would say little about the language as in most cases you are using different web servers (apache , lighthttpd, resin etc) or modules on the same web server (say mod_perl vs mod_php). So your conclusion would apply to an whole framework and not the language in itself.

So then in the example you gave you'd be benchmarking frameworks against each other. But these benchmarks would say little about the language as in most cases you are using different web servers (apache , lighthttpd, resin etc) or modules on the same web server (say mod_perl vs mod_php). So your conclusion would apply to an whole framework and not the language in itself.
Right. But web developers simply want to know - if I choose Ruby (or PHP), will my website run faster? And what you find in a typical benchmark (like so-called language shootouts) often confuses web developers into thinking that 'PHP is faster than Ruby' or 'Ruby is faster than PHP'.

If someone really needs performance for data mining or sorting tasks - they wouldn't use Ruby or PHP anyway.

if they need performance for data mining, what would they use?

C or C++. Maybe C#/Java.

I'm new to Ruby... can one do everything with Ruby w/ Rails that they can with PHP?

You can do what PHP does with ANY language. try lisp

Well in some sense yes there is "exotic" hardware out there that can do particular things very well. But on typical "PC" hardware there isn't that much difference.
Graphics cards are wonderful at vector math =p.

if they need performance for data mining, what would they use?
Probably a declarative language like SQL. Though I'm not an expert in the field, I would suspect that SQL is widely used to do the 'real work', with something quick to develop in on the front-end (performance doesn't really matter, since the gruntwork is done elsewhere). Ruby would be pretty useful for that job ;).

Also I've yet to experience an example where a major improvement occured while changing the implementation of an algorithm. Its always a theoretical change in the algorithm that causes big improvements.
The whole point of comparing languages is to emphasize the minor improvement gained by using a different underlying implementation of the structures the algorithm uses. You're not going to get a vast *absolute* difference (though the mentioned array concatenation issue could certainly generate one) between implementations, but when taken in the scope of the benchmark, it could be very significant. If your test takes 10 minutes to run, and you cut it down by 30 seconds, this isn't an optimisation to write home about. However, if the language you're comparing it to takes 9 minutes to run the same test, you just halved the performance delta.

Of course, I agree with you. A sane benchmark would compare the best case of each language.

Right. But web developers simply want to know - if I choose Ruby (or PHP), will my website run faster? And what you find in a typical benchmark (like so-called language shootouts) often confuses web developers into thinking that 'PHP is faster than Ruby' or 'Ruby is faster than PHP'.

If someone really needs performance for data mining or sorting tasks - they wouldn't use Ruby or PHP anyway.
The problem is that that's virtually impossible to benchmark objectively. There are far too many variables. Generally, in any experiment, you want to reduce the number of variables to 1, if possible. You could conceivably write the exact same web application in multiple frameworks, and then test it against various web serve platforms, but the amount of work is prohibitive, and aside from that, there are still a ton of uncertainties. Programmer skill and experience with the languages becomes a huge issue since so much code is involved. Such a benchmark would be essentially useless; there's no way at all to verify that the information is valid, that the code doesn't favour one language or another, that the web server and module configurations were appropriate, that the developed application was in any way 'typical' of web applications in general.

The only way to have even a glimmer of an idea of which language is faster is to break the problem down. Is Ruby (the language) faster than PHP (the language)? Is lighttpd faster than Apache? Does either of mod_ruby or mod_php introduce significantly more overhead? Is fastcgi better or worse than using Apache the module for Ruby? These sorts of things can be tested with some accuracy, and if all the information were compiled, it might provide something useful for web developers on the whole. Giving only one part of the picture can definitely be misleading, but it's still useful information to have.

That said, I really don't think it matters whatsoever to 99.9% web developers. Neither language is so much faster than the other that it's going to make any appreciable difference. I suspect that the real-world difference between two comparable frameworks (where the only difference is language used) for an application written by experienced developers is on the order of one page per second at most. What matters far more to the actual developer is how much time it took him to develop the application, and how easily it can be maintained. These are things that can't be benchmarked and aren't really mentioned when people ask which language is best. If a developer can write a functionally identical application in 1/2 the time by learning a new language, he can potentially make twice as much money. That's probably worth looking into.

I'm new to Ruby... can one do everything with Ruby w/ Rails that they can with PHP?
Both are Turing-complete. In theory you can perform any task a computer can perform in either language. In practice that's a pretty useless statement. PHP is a more 'mature', popular language, which means there are probably more add-on modules and sources out there for you to use. The built-in library is also one of the reasons that it became popular in the first place; in one huge namespace are functions to do virtually anything a C library exists to do. Ruby has a much more conservative default loadout, but there are lots of addon modules you can find to perform pretty much any task you can do in PHP. I also suspect that it's a lot easier to interface with C libraries that don't have a module available than it is with PHP, but that's just speculation. In any case, for all intents and purposes (regarding the end result), yes you can do everything in Ruby that you can in PHP. Ruby does support a lot more syntactic rules that make your life easier though (especially with Rails), which could each be taken as something PHP can't do.

PHP is faster, especially with mod_cache, eAccelerator or phpaccelerator and the like.

You can write complex web applications in Ruby (with Rails) or Python (with TurboGears or Django or QP or Quixote or CherryPy or Zope or ...) much faster, I'd argue, than with any modern PHP 'framework'.

You can write non-web applications with equal productivity in Python, and to a slightly lesser extent Ruby although these differences will tend to evaporate over time. Python has excellent support for cross platform development. Does PHP run on a Nokia telephone and an IBM mainframe? Would you write a graphical editor, or a spreadsheet in PHP? You certainly could in Python.

At this point Python support for cross platform Windowing applications (using wxWidgets or Qt or GTK or a few other lesser invoked toolkit bases) edges out Ruby somewhat and far eclipses PHP.

As for raw performance, Python edges Ruby out somewhat in speed; both are faster than PHP for most operations. But what you really care about is how they perform in your application domain. If you are writing web apps - then that's how they should be measured, and that's where they get difficult to measure.

Your best bet is to install Ruby or Python and PHP versions of actual applications and then do some benchmarking. For example find a Wiki like Instiki (Ruby) or one of the many Python wikis and a PHP wiki.

Install all. Run some "ab" performance benchmarks.

I think you'll find that in a moderately complex application, all three perform about the same. If you design your data access badly in any of them (80 queries per request plus connection and tear down syndrome so common in many PHP apps) then you'll see correspondingly bad performance.

But when you do these tests you'll need to read some code and be sure you are testing apples to apples. Are the apps doing the same thing for a given request? Is one generating the page entirely dynamically while another is simply pushing out an already cached rendering (not a bad idea in any case)?

I put up a copy of Typo just now (from subversion), a Ruby on Rails app, and, after patching a bug in its migration code, did some testing. Python blog software to Ruby/Rails blog software.

Tried to keep the environment the same for both. Environment - running the built in 'webbrick' http server. In theory this ought to be a reasonable performer and allows one to benchmark without involving Apache or lighttpd or whatever. Python has similar web servers and the frame work I use, 'QP' ( a cousin of Quixote ), employs same (or can run as SCGI app behind Apache or lighttpd).

In each case the article being pulled out contained a single word 'test', with no Markdown markup, although Markdown was enabled (Ruby, Rails, Typo):
% ab -n100 http://localhost:3000/articles/2006/05/28/test
Document Length: 6832 bytes
Concurrency Level: 1
Time taken for tests: 69.762 seconds
Complete requests: 100
Requests per second: 1.43 [#/sec] (mean)
Time per request: 697.62 [ms] (mean)
With Markdown off - much the same result.

Could this simply be that webbrick isn't able to handle much? Possibly. ab reports that a real live typo install on a machine next to mine in the same data center can return 70 requests per second. That's much better. curl -I reports that machine is running Apache and FastCGI.

Lets compare python web server to ruby web server (redbrick) - A Python relatively full featured blog with no page caching, similar 1 word test, markdown enabled (Python / QP / 'Parlez'):

% ab -n100 http://localhost:8083/blogs/mw/FooBar/
Document Path: /blogs/mw/FooBar/
Time taken for tests: 0.557 seconds
Complete requests: 100
Requests per second: 179.53 [#/sec] (mean)
Time per request: 5.57 [ms] (mean)
Without markdown enabled: Requests per second: 212.31 [#/sec] (mean)

Now a single word page is not a very good test for either - Markdown (like Textile and ReST and other page 'markup' languages) takes significant time to process. A moderately complex page in Markdown, if reparsed on every hit, would put a big load on any machine, any language, but more so on the PHP boxen.

A useful next step would be to compare Ruby and Python (and PHP) processing the same test text - say pick Textile, since its available on all three language platforms - and write a simple timed benchmark - no web access, just raw string processing. My guess is Python and Ruby both beat PHP and I'll do a test one of these days if asked.

As others have pointed out in this thread one shouldn't make a PHP to Ruby or PHP to Python comparison unless its on pure language features and processing - not web execution. If you want to compare performance on the web then you've got to compare PHP to some Ruby or Python framework, and there are many of them. Some are incredibly complex, some are light and fast. Some use a lot of "magic" and some disdain magic. PHP has its own share of frameworks too.

No doubt this muddies waters more but might be useful for some.

PS, I should note in the above test that I purposely ran the typo blog in "dev" environment rather than "production", otherwise typo would use a file-based page cache. For the curious, that raises typo's performance, of course -- Requests per second: 63.65 [#/sec] (mean).

The python example I gave didn't use a page cache. Enabling that brings performance up another notch: Requests per second: 217.39 [#/sec] (mean).

Lets make pages sizes identical and run 1000 requests, concurrency level 1 and 4 for each. Highest of three runs each. Test run on a fairly heavily loaded development machine, not on a "server". Both the python and ruby apps run as daemons in a somewhat typical environment. This is a single CPU box, FreeBSD 6.1:
concurrent req 1 4
Ruby 63 r/s 57 r/s
Python 193 r/s 190 r/s
Lets run that same test on an older dual CPU server, FreeBSD 4.11:

concurrent req 1 4
Ruby 52 r/s 38 r/s
Python 169 r/s 301 r/s
(We might see slightly improved performance on FreeBSD 6.1 on the dual CPU tests)

I believe this is a representative comparison between Ruby and Python doing similar work. What this probably shows more than anything is that Rails, which has a lot of magic going on behind the covers, has a cost. However is that cost meaningful? Perhaps not. 50 - 60 requests per second on commodity hardware for a dynamic web application is not bad at all.

Still, I'm not unhappy with getting 300 requests per second out of the Python app ;)

i've tried ruby. i like the ruby syntax.

But in the end, i stick with php.

why? BECAUSE it's so much easier to do web stuff with php with the AMOUNT Of LIBRARIES, and DOCUMENTATION available.

I love both. I love PHP. I love Ruby. I really like the Ruby on Rails framework. I can do the same tasks with both, even though PHP takes more code. At the end of the day do what you enjoy. Both technologies run well, though webrick (default webserver with RoR) is horribly inefficient. At times, I like the sheer productivity RoR brings to a project, especially when rolling out an application from start to finish. On the other hand, I like PHP's verbosity, controlling exactly what happens with precision. Once again, just do what you enjoy and don't worry about the rest.

yup. I love ruby on rails. which is why i created my own php version of it.

You mean PHP on Trax (http://www.phpontrax.com/)?

nope. php on trax uses PEAR heavily and i hate pear. I build my own replica.

quite a waste of time but at least i get to use the best tools like PDO instead of PEAR::DB

I love both. I love PHP. I love Ruby. I really like the Ruby on Rails framework. I can do the same tasks with both, even though PHP takes more code. At the end of the day do what you enjoy. Both technologies run well, though webrick (default webserver with RoR) is horribly inefficient.

That's why you just use it for development....use fastcgi/scgi (though i've yet to use scgi) for production mode. Using lighttpd instead of apache seems to offer some improvement though I don't have specific benchmarks.