Under the hood, Ruby *is *compiled to bytecode at load time, but it's still 
difficult to optimise because of the fact that everything is defined and 
dispatched dynamically, and any value can potentially redefine nearly any 
operation on it! The case statement is a perfect example: each "when" 
branch invokes what might be a completely different === method, so there's 
no way to convert that to a simple jump.

Charles Nutter has made some great blog posts and talks about the 
optimisation difficulties he has come across while implementing JRuby 
(which seems to be the most performance-optimised Ruby implementation).

http://blog.headius.com/2012/10/so-you-want-to-optimize-ruby.html

http://www.confreaks.com/videos/3192-rubyconfau2013-high-performance-ruby

On Wednesday, August 6, 2014 10:47:06 AM UTC+10, Marky Mark wrote:
>
> I would say rather that C is *faster*, not more functional. But no 
> surprises there. Ruby is not the fastest kid off the block from my first 
> impressions. But then what interpreted language is? Although I suppose if 
> there is a Ruby compiler out there then it could, in the right conditions, 
> optimise the case statement similarly to the C compiler.
>
> On Wednesday, August 6, 2014 9:07:19 AM UTC+10, Clifford Heath wrote:
>>
>> On 5 Aug 2014, at 5:46 pm, Marky Mark <[email protected]> wrote: 
>> > ...It made me go back and look at C++'s switch statement (see a 
>> just-prior posting) and feel frustrated that C++ doesn't support such 
>> flexibility. 
>>
>> The Ruby case statement is just a fancy syntax for if… else if…else if… 
>> else. 
>> C applies Occam’s razor, not multiplying features needlessly. On the 
>> other hand, 
>> its switch statement does something that is well-supported by the 
>> hardware, but 
>> unavailable in Ruby; namely, allowing the compiler to decide when to use 
>> jump 
>> tables to get super-fast selection of cases. 
>>
>> Feel frustrated all you like, but C is *more* functional than Ruby in 
>> this situation, 
>> not less. 
>>
>> Clifford Heath. 
>>
>> > (I mean not even support the generic object.equals syntax, never mind a 
>> closure.) That's the kind of thing that highlights why one might bother 
>> with Ruby at all. If you don't get the cleverness presented to you, you 
>> might never find out about it. 
>> > 
>> > On Tuesday, August 5, 2014 5:22:31 PM UTC+10, Dan Harper wrote: 
>> > On 5 Aug 2014, at 4:24 pm, Tim Moore <[email protected]> 
>> wrote: 
>> >> One thing that hasn't been mentioned yet, and which unfortunately I 
>> couldn't really address in the talk without a long tangent, is why would 
>> you want to write code like this in the first place? Is a proc in a case 
>> statement anything but a useless, overly-clever bit of language esoterica? 
>> > 
>> > I had the same thought. After some musing, I came to the conclusion 
>> that you should opt for simpler code using simple concepts and cop the 
>> penalty of it being more verbose. Not everyone will agree I’m sure, and 
>> that’s cool. 
>> > 
>> > The advantages of having simpler code using simple concepts is that 
>> your code is now more easily understood by other developers with a lower 
>> level of Ruby knowledge.  This is the same reason I try to not perform Ruby 
>> gymnastics in tests. If I do decide to use some more complex code, I use 
>> comments to explain what I’m doing. 
>> > 
>> > This was probably more important back in the day when hardly anyone 
>> used Ruby, but I still follow it. 
>> > 
>> > If you’re just consuming gems (not authoring them) and say, coding in 
>> Rails, you’ll rarely have a need to use Proc or similar concepts. So when 
>> you’re learning, I’d say don’t bother with Proc and fancy Ruby concepts. 
>> Learn other things that will get you more productive at a faster rate. 
>> > 
>> > Dan 
>> > 
>> > 
>> > Dan Harper 
>> > [email protected] 
>> > Mobile:  0414 344 233 
>> > 
>> > 
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google 
>> Groups "Ruby or Rails Oceania" group. 
>> > To unsubscribe from this group and stop receiving emails from it, send 
>> an email to [email protected]. 
>> > To post to this group, send email to [email protected]. 
>> > Visit this group at http://groups.google.com/group/rails-oceania. 
>> > For more options, visit https://groups.google.com/d/optout. 
>>
>>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
or Rails Oceania" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/rails-oceania.
For more options, visit https://groups.google.com/d/optout.

Reply via email to