<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Are you concerned about ruby being slow?</title>
	<atom:link href="http://www.rubyfleebie.com/are-you-concerned-about-ruby-being-slow/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.rubyfleebie.com/are-you-concerned-about-ruby-being-slow/</link>
	<description>Because programming should be fun</description>
	<lastBuildDate>Thu, 15 Jul 2010 19:48:22 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Adam McClure</title>
		<link>http://www.rubyfleebie.com/are-you-concerned-about-ruby-being-slow/comment-page-1/#comment-306</link>
		<dc:creator>Adam McClure</dc:creator>
		<pubDate>Fri, 20 Jul 2007 06:50:37 +0000</pubDate>
		<guid isPermaLink="false">http://www.rubyfleebie.com/are-you-concerned-about-ruby-being-slow/#comment-306</guid>
		<description>I am not worried about speed.  I believe the Ruby development team will take Ruby to the next level regardless of whether YARV is used or not.

Connecting to multiple databases has been sorted out.</description>
		<content:encoded><![CDATA[<p>I am not worried about speed.  I believe the Ruby development team will take Ruby to the next level regardless of whether YARV is used or not.</p>
<p>Connecting to multiple databases has been sorted out.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: siroj</title>
		<link>http://www.rubyfleebie.com/are-you-concerned-about-ruby-being-slow/comment-page-1/#comment-297</link>
		<dc:creator>siroj</dc:creator>
		<pubDate>Thu, 12 Jul 2007 09:45:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.rubyfleebie.com/are-you-concerned-about-ruby-being-slow/#comment-297</guid>
		<description>1. yes, I&#039;m concerned about it. but what I concerned more is the fact that ruby&#039;s thread is plain suck, is modern age already, why still use process. I also disagree with DHH argument in this case, process does indeed easier to manage in code, because actually nothing to manage, but thread is more powerful because it is (quite) dangerous (code &amp; var sharing). I hope YARV will fix it
2. I&#039;ve said it in my answer to the 1st question, yes I have (quite) high hope for YARV. but does anyone know about the progress of the project ??</description>
		<content:encoded><![CDATA[<p>1. yes, I&#8217;m concerned about it. but what I concerned more is the fact that ruby&#8217;s thread is plain suck, is modern age already, why still use process. I also disagree with DHH argument in this case, process does indeed easier to manage in code, because actually nothing to manage, but thread is more powerful because it is (quite) dangerous (code &amp; var sharing). I hope YARV will fix it<br />
2. I&#8217;ve said it in my answer to the 1st question, yes I have (quite) high hope for YARV. but does anyone know about the progress of the project ??</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jesse</title>
		<link>http://www.rubyfleebie.com/are-you-concerned-about-ruby-being-slow/comment-page-1/#comment-207</link>
		<dc:creator>jesse</dc:creator>
		<pubDate>Wed, 16 May 2007 20:09:36 +0000</pubDate>
		<guid isPermaLink="false">http://www.rubyfleebie.com/are-you-concerned-about-ruby-being-slow/#comment-207</guid>
		<description>I had read this article a while ago, comparing the different VMs.
http://www.antoniocangiano.com/articles/2007/02/19/ruby-implementations-shootout-ruby-vs-yarv-vs-jruby-vs-gardens-point-ruby-net-vs-rubinius-vs-cardinal

He hasn&#039;t run the 2nd batch of tests like h said, but it&#039;ll be interesting to see those results too.

I&#039;ll be at RailsConf &#039;07 and I&#039;ll have to say, this session:
http://conferences.oreillynet.com/cs/rails2007/view/e_sess/14480
on scaling Rails apps on Amazon&#039;s EC2 service has me quite excited.</description>
		<content:encoded><![CDATA[<p>I had read this article a while ago, comparing the different VMs.<br />
<a href="http://www.antoniocangiano.com/articles/2007/02/19/ruby-implementations-shootout-ruby-vs-yarv-vs-jruby-vs-gardens-point-ruby-net-vs-rubinius-vs-cardinal" rel="nofollow">http://www.antoniocangiano.com/articles/2007/02/19/ruby-implementations-shootout-ruby-vs-yarv-vs-jruby-vs-gardens-point-ruby-net-vs-rubinius-vs-cardinal</a></p>
<p>He hasn&#8217;t run the 2nd batch of tests like h said, but it&#8217;ll be interesting to see those results too.</p>
<p>I&#8217;ll be at RailsConf &#8216;07 and I&#8217;ll have to say, this session:<br />
<a href="http://conferences.oreillynet.com/cs/rails2007/view/e_sess/14480" rel="nofollow">http://conferences.oreillynet.com/cs/rails2007/view/e_sess/14480</a><br />
on scaling Rails apps on Amazon&#8217;s EC2 service has me quite excited.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: syh</title>
		<link>http://www.rubyfleebie.com/are-you-concerned-about-ruby-being-slow/comment-page-1/#comment-194</link>
		<dc:creator>syh</dc:creator>
		<pubDate>Thu, 03 May 2007 15:29:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.rubyfleebie.com/are-you-concerned-about-ruby-being-slow/#comment-194</guid>
		<description>it seems that YARV is good enough

http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&amp;lang=ruby&amp;lang2=yarv

http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&amp;lang=all</description>
		<content:encoded><![CDATA[<p>it seems that YARV is good enough</p>
<p><a href="http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&amp;lang=ruby&amp;lang2=yarv" rel="nofollow">http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&amp;lang=ruby&amp;lang2=yarv</a></p>
<p><a href="http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&amp;lang=all" rel="nofollow">http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&amp;lang=all</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jason Morrison</title>
		<link>http://www.rubyfleebie.com/are-you-concerned-about-ruby-being-slow/comment-page-1/#comment-179</link>
		<dc:creator>Jason Morrison</dc:creator>
		<pubDate>Tue, 24 Apr 2007 01:21:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.rubyfleebie.com/are-you-concerned-about-ruby-being-slow/#comment-179</guid>
		<description>comment form stole my link! : )

http://eigenclass.org/hiki/non-synthetic-benchmarks-for-yarv</description>
		<content:encoded><![CDATA[<p>comment form stole my link! : )</p>
<p><a href="http://eigenclass.org/hiki/non-synthetic-benchmarks-for-yarv" rel="nofollow">http://eigenclass.org/hiki/non-synthetic-benchmarks-for-yarv</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jason Morrison</title>
		<link>http://www.rubyfleebie.com/are-you-concerned-about-ruby-being-slow/comment-page-1/#comment-178</link>
		<dc:creator>Jason Morrison</dc:creator>
		<pubDate>Tue, 24 Apr 2007 01:21:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.rubyfleebie.com/are-you-concerned-about-ruby-being-slow/#comment-178</guid>
		<description>Maybe actual numbers will be more useful than guessing? .  Should be a few more articles on eigenclass on the topic iirc.  You can try also Rails on YARV for yourself, btw...</description>
		<content:encoded><![CDATA[<p>Maybe actual numbers will be more useful than guessing? .  Should be a few more articles on eigenclass on the topic iirc.  You can try also Rails on YARV for yourself, btw&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: juantar</title>
		<link>http://www.rubyfleebie.com/are-you-concerned-about-ruby-being-slow/comment-page-1/#comment-177</link>
		<dc:creator>juantar</dc:creator>
		<pubDate>Mon, 23 Apr 2007 19:30:42 +0000</pubDate>
		<guid isPermaLink="false">http://www.rubyfleebie.com/are-you-concerned-about-ruby-being-slow/#comment-177</guid>
		<description>1) Yes, I am very concerned. Some of us want to bring Game Programming to Ruby and for that we need a fast interpreter.

2) Yes I have faith in YARV. I have to have faith in it :).</description>
		<content:encoded><![CDATA[<p>1) Yes, I am very concerned. Some of us want to bring Game Programming to Ruby and for that we need a fast interpreter.</p>
<p>2) Yes I have faith in YARV. I have to have faith in it :).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Peter Cooper</title>
		<link>http://www.rubyfleebie.com/are-you-concerned-about-ruby-being-slow/comment-page-1/#comment-176</link>
		<dc:creator>Peter Cooper</dc:creator>
		<pubDate>Mon, 23 Apr 2007 14:43:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.rubyfleebie.com/are-you-concerned-about-ruby-being-slow/#comment-176</guid>
		<description>I&#039;m as worried about Ruby&#039;s performance versus Python as I am about C&#039;s performance versus hand-written assembler. That is, not at all. There are some people in this world who live for benchmark numbers, and some of us who are pragmatic and live for actual results.

I&#039;ve ported Perl scripts to Ruby which have then been significantly faster on Ruby, not because the language is faster but because the libraries used have been better written, have used C extensions, and any number of factors. A great coder in Ruby will kick an average Python programmer in the ass, so it&#039;s not always down to the speed of the language but the programmer.

One great example of this is in the land of SQL. It seems most developers have only a basic knowledge of SQL (particularly people who write forum software for some reason..) and design some absolutely hideous databases and queries and expect the RDBMS to sort it all out (which it doesn&#039;t). It&#039;s not rare for a semi-competent SQL developer&#039;s code to outperform crappy SQL code by 10 to 100 times or more, simply because they know what they&#039;re doing and can compress an operation into, say, 10 rapid database operations rather than 1 humongous join that takes five minutes to run.

So.. more Ruby performance is always a good thing, but more important is skill, understanding algorithms, and being able to see the big picture of optimization rather than the raw speed of the language.

If you threw me in a Formula 1 car, I bet I&#039;d still drive like crap, and Michael Schumacher could probably beat me in a Mercedes SL no troubles. It&#039;s the skill, not the tool.</description>
		<content:encoded><![CDATA[<p>I&#8217;m as worried about Ruby&#8217;s performance versus Python as I am about C&#8217;s performance versus hand-written assembler. That is, not at all. There are some people in this world who live for benchmark numbers, and some of us who are pragmatic and live for actual results.</p>
<p>I&#8217;ve ported Perl scripts to Ruby which have then been significantly faster on Ruby, not because the language is faster but because the libraries used have been better written, have used C extensions, and any number of factors. A great coder in Ruby will kick an average Python programmer in the ass, so it&#8217;s not always down to the speed of the language but the programmer.</p>
<p>One great example of this is in the land of SQL. It seems most developers have only a basic knowledge of SQL (particularly people who write forum software for some reason..) and design some absolutely hideous databases and queries and expect the RDBMS to sort it all out (which it doesn&#8217;t). It&#8217;s not rare for a semi-competent SQL developer&#8217;s code to outperform crappy SQL code by 10 to 100 times or more, simply because they know what they&#8217;re doing and can compress an operation into, say, 10 rapid database operations rather than 1 humongous join that takes five minutes to run.</p>
<p>So.. more Ruby performance is always a good thing, but more important is skill, understanding algorithms, and being able to see the big picture of optimization rather than the raw speed of the language.</p>
<p>If you threw me in a Formula 1 car, I bet I&#8217;d still drive like crap, and Michael Schumacher could probably beat me in a Mercedes SL no troubles. It&#8217;s the skill, not the tool.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Calamitous</title>
		<link>http://www.rubyfleebie.com/are-you-concerned-about-ruby-being-slow/comment-page-1/#comment-175</link>
		<dc:creator>Calamitous</dc:creator>
		<pubDate>Mon, 23 Apr 2007 06:48:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.rubyfleebie.com/are-you-concerned-about-ruby-being-slow/#comment-175</guid>
		<description>1) Are you concerned about ruby being slow?
Short answer: no.  Machines are cheaper than people.
2) Do you have faith in YARV?
Again, no, because I don&#039;t think Ruby&#039;s performance is what&#039;s holding it back -- people&#039;s *concern* over Ruby&#039;s performance is.  Twitter&#039;s problems (11,000+ reqs/sec) are in a realm beyond what most of us will deal with, but my $JOB&#039;s primary application is written in Rails, and supports 200 employees and 7000-8000 users on one server.  Adding another server is as easy as setting up the new box and adding a line to my proxy balancer config.

Selling Ruby and Rails as a platform to mgmt was much, much harder than implementing it.</description>
		<content:encoded><![CDATA[<p>1) Are you concerned about ruby being slow?<br />
Short answer: no.  Machines are cheaper than people.<br />
2) Do you have faith in YARV?<br />
Again, no, because I don&#8217;t think Ruby&#8217;s performance is what&#8217;s holding it back &#8212; people&#8217;s *concern* over Ruby&#8217;s performance is.  Twitter&#8217;s problems (11,000+ reqs/sec) are in a realm beyond what most of us will deal with, but my $JOB&#8217;s primary application is written in Rails, and supports 200 employees and 7000-8000 users on one server.  Adding another server is as easy as setting up the new box and adding a line to my proxy balancer config.</p>
<p>Selling Ruby and Rails as a platform to mgmt was much, much harder than implementing it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Smokinn</title>
		<link>http://www.rubyfleebie.com/are-you-concerned-about-ruby-being-slow/comment-page-1/#comment-174</link>
		<dc:creator>Smokinn</dc:creator>
		<pubDate>Mon, 23 Apr 2007 05:45:28 +0000</pubDate>
		<guid isPermaLink="false">http://www.rubyfleebie.com/are-you-concerned-about-ruby-being-slow/#comment-174</guid>
		<description>I don&#039;t think presenting Twitter as a model of Ruby scaling is at all valid.

First, are you talking about Ruby or are you talking about Ruby on Rails? Two very separate things.

Ruby, like you say, is slower than Python. Whether this will still be true when Yarv comes along we don&#039;t know. Either way, I say it doesn&#039;t matter. It doesn&#039;t matter because the vast majority of a program isn&#039;t all that affected by computation speed, especially when talking about a web application. Not only that, but if your program is sluggish, you can easily profile your application and, if it&#039;s not possible to optimize it more, replace the bottleneck entirely with C. It&#039;s actually very easy to do in Ruby.

Now for Rails. The twitter case I&#039;m not really happy about people using as an example of scalability. First off, they can get up to 12,000 hits/second. That&#039;s a massive amount of traffic. Their first bottleneck was computational but when they added more mongrel servers, this bottleneck was resolved. Their complaint is that it&#039;s difficult to connect one application to multiple databases with Rails. As DHH pointed out, this is true of any single-stack framework. This however, has nothing to do with the speed of Ruby. Twitter&#039;s bottleneck is the database connection. Changing to Yarv, even if Yarv is two, three or 100 times faster will do nothing for them since it won&#039;t affect their bottleneck. They might be able to run less mongrel servers but overall there will be no change. So really it&#039;s a Rails framework problem (the ability to easily connect to multiple database), not a Ruby problem.

And when thinking about whether you should adopt RoR or not based on scalability issues, consider when you&#039;ll be getting to 12,000 hits/second and whether by then the ability to connect to multiple databases will be included in Rails, either because the Twitter guys figured it out and published how or someone else did. Even the twitter guys didn&#039;t say it&#039;s impossible. I&#039;ve never tried so I don&#039;t know myself. They just said it&#039;s not as easy as everything else in Rails and that&#039;s why they were complaining.</description>
		<content:encoded><![CDATA[<p>I don&#8217;t think presenting Twitter as a model of Ruby scaling is at all valid.</p>
<p>First, are you talking about Ruby or are you talking about Ruby on Rails? Two very separate things.</p>
<p>Ruby, like you say, is slower than Python. Whether this will still be true when Yarv comes along we don&#8217;t know. Either way, I say it doesn&#8217;t matter. It doesn&#8217;t matter because the vast majority of a program isn&#8217;t all that affected by computation speed, especially when talking about a web application. Not only that, but if your program is sluggish, you can easily profile your application and, if it&#8217;s not possible to optimize it more, replace the bottleneck entirely with C. It&#8217;s actually very easy to do in Ruby.</p>
<p>Now for Rails. The twitter case I&#8217;m not really happy about people using as an example of scalability. First off, they can get up to 12,000 hits/second. That&#8217;s a massive amount of traffic. Their first bottleneck was computational but when they added more mongrel servers, this bottleneck was resolved. Their complaint is that it&#8217;s difficult to connect one application to multiple databases with Rails. As DHH pointed out, this is true of any single-stack framework. This however, has nothing to do with the speed of Ruby. Twitter&#8217;s bottleneck is the database connection. Changing to Yarv, even if Yarv is two, three or 100 times faster will do nothing for them since it won&#8217;t affect their bottleneck. They might be able to run less mongrel servers but overall there will be no change. So really it&#8217;s a Rails framework problem (the ability to easily connect to multiple database), not a Ruby problem.</p>
<p>And when thinking about whether you should adopt RoR or not based on scalability issues, consider when you&#8217;ll be getting to 12,000 hits/second and whether by then the ability to connect to multiple databases will be included in Rails, either because the Twitter guys figured it out and published how or someone else did. Even the twitter guys didn&#8217;t say it&#8217;s impossible. I&#8217;ve never tried so I don&#8217;t know myself. They just said it&#8217;s not as easy as everything else in Rails and that&#8217;s why they were complaining.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
