Ruby people should be more candid about the performance situation, which is a catastraphuck. It is worth it, it will probably get better, and raw performance isn't that important for I/O bound apps, but Ruby is noticeably slower than pretty much all its competitors.
People make this claim all the time but I never hear anyone talk about actual examples where they were bitten by this.
People especially like to harp on the speed of ruby as a knock on ruby on rails. However I have not once run into a real life situation where the performance problem was directly related to the raw performance of Ruby. I have though run into plenty of performance problems:
* At Odeo (RoR circa 2005) we had plenty of problems with memory leaks in our FCGI (this was 2005!) processes and in feed_tools (well known to be slow)
* At my next company we quickly ran into situations where pages were slow to load due to the sheer number of database calls. When I started doing web apps I can remember never having more than three queries behind any given page. Some of our pages were doing 500 queries. This was easily fixed but Rails definitely tempts you to put up scaffolding which you then have to rework once it starts getting real use. In my experience this is a good thing. I'm twice as likely to throw away the scaffolding than I am to have to rewrite it.
* Twitter, which is the poster child for RoR scaling issues, actually actually has had almost all their problems on the backend, having to rapidly change their database and message queue architectures and deal with flaky service providers (AOL and phone companies). Again nothing to do with the architecture they launched with.
So, in the lab Ruby is a slow language, but in the real world how is this biting people?
Like I said earlier, our app parses with racc, does cryptography, and a fair bit of analysis. It is not heavily database dependent. Most of our I/O is memcached. I assert without evidence that Ruby's performance deficits have in fact bit us.
Comments
Ruby people should be more candid about the performance situation, which is a catastraphuck. It is worth it, it will probably get better, and raw performance isn't that important for I/O bound apps, but Ruby is noticeably slower than pretty much all its competitors.
People make this claim all the time but I never hear anyone talk about actual examples where they were bitten by this.
People especially like to harp on the speed of ruby as a knock on ruby on rails. However I have not once run into a real life situation where the performance problem was directly related to the raw performance of Ruby. I have though run into plenty of performance problems:
* At Odeo (RoR circa 2005) we had plenty of problems with memory leaks in our FCGI (this was 2005!) processes and in feed_tools (well known to be slow)
* At my next company we quickly ran into situations where pages were slow to load due to the sheer number of database calls. When I started doing web apps I can remember never having more than three queries behind any given page. Some of our pages were doing 500 queries. This was easily fixed but Rails definitely tempts you to put up scaffolding which you then have to rework once it starts getting real use. In my experience this is a good thing. I'm twice as likely to throw away the scaffolding than I am to have to rewrite it.
* Twitter, which is the poster child for RoR scaling issues, actually actually has had almost all their problems on the backend, having to rapidly change their database and message queue architectures and deal with flaky service providers (AOL and phone companies). Again nothing to do with the architecture they launched with.
So, in the lab Ruby is a slow language, but in the real world how is this biting people?
Like I said earlier, our app parses with racc, does cryptography, and a fair bit of analysis. It is not heavily database dependent. Most of our I/O is memcached. I assert without evidence that Ruby's performance deficits have in fact bit us.