[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: Performance diffrence between ifs and case

Phlip

7/28/2007 8:20:00 PM

forgottenwizard wrote:

> What kind of diffrences are there, effectivly, between case and a series
> of if statements, like in this:

Google for "premature optimization is the root of all evil".

Ruby is not the most performant language on the block, and both those
statements will resolve to a chain of conditionals. You need to devote your
time to making clear readable code that's easy to upgrade. When the time
comes to speed it up, if you have unit tests, you can change it easily,
while profiling to see what's actually slow. Trying to guess what will be
slow will only make you waste time writing complex code.

The most important resource to optimize is programmer time.

--
Phlip
http://www.oreilly.com/catalog/9780...
^ assert_xpath
http://tinyurl.... <-- assert_raise_message
8 Answers

Phlip

7/28/2007 8:32:00 PM

0

forgottenwizard wrote:

> Okay, to sum up what you said, not a damn thing? Thats all the answer I
> needed, not an explination why I shouldn't bother to care how to do
> things properly, or why I would not want to try and learn a little more
> on the internals of a language.

Ah, but I said it much more diplomatically than Tony Hoare and/or Don Knuth
did!

Learn the internals of Ruby; they rock. However, optimization is a sore-spot
around here, because the language is slower than molasses in January (in
the Norther Hemisphere).

--
Phlip
http://www.oreilly.com/catalog/9780...
^ assert_xpath
http://tinyurl.... <-- assert_raise_message

forgottenwizard

7/29/2007 1:34:00 AM

0

On 10:29 Sun 29 Jul , Phlip wrote:
> forgottenwizard wrote:
>
> > What kind of diffrences are there, effectivly, between case and a series
> > of if statements, like in this:
>
> Google for "premature optimization is the root of all evil".
>
> Ruby is not the most performant language on the block, and both those
> statements will resolve to a chain of conditionals. You need to devote your
> time to making clear readable code that's easy to upgrade. When the time
> comes to speed it up, if you have unit tests, you can change it easily,
> while profiling to see what's actually slow. Trying to guess what will be
> slow will only make you waste time writing complex code.
>
> The most important resource to optimize is programmer time.
>
> --
> Phlip
> http://www.oreilly.com/catalog/9780...
> ^ assert_xpath
> http://tinyurl.... <-- assert_raise_message
>

Okay, to sum up what you said, not a damn thing? Thats all the answer I
needed, not an explination why I shouldn't bother to care how to do
things properly, or why I would not want to try and learn a little more
on the internals of a language.

John Joyce

7/29/2007 1:53:00 AM

0

Or, just write code using case, then code using if's
then test it.
Ruby has a testing facility in the standard library!
That's the quickest way to find out.

forgottenwizard

7/29/2007 2:05:00 AM

0

On 10:53 Sun 29 Jul , John Joyce wrote:
> Or, just write code using case, then code using if's
> then test it.
> Ruby has a testing facility in the standard library!
> That's the quickest way to find out.
>

Is there any idea on which way the aforementioned systems will evolve,
or is that kind of a toss-up.

What I'm doing right now, it doesn't make much of a diff either way, so
I'll use case sinces its less typing...

Phlip

7/29/2007 2:41:00 AM

0

forgottenwizard wrote:

> Is there any idea on which way the aforementioned systems will evolve,
> or is that kind of a toss-up.

There's at least one attempt out there to write a compiler for Ruby. That
requires a re-write, and while of course its goal is more performance, the
exact resulting mix will indeed be a toss-up.

> What I'm doing right now, it doesn't make much of a diff either way, so
> I'll use case sinces its less typing...

So ... 'case' is more "DRY"?

--
Phlip
http://www.oreilly.com/catalog/9780...
"Test Driven Ajax (on Rails)"
assert_xpath, assert_javascript, & assert_ajax


forgottenwizard

7/29/2007 4:10:00 AM

0

On 11:41 Sun 29 Jul , Phlip wrote:
> forgottenwizard wrote:
>
> >Is there any idea on which way the aforementioned systems will evolve,
> >or is that kind of a toss-up.
>
> There's at least one attempt out there to write a compiler for Ruby. That
> requires a re-write, and while of course its goal is more performance, the
> exact resulting mix will indeed be a toss-up.
>
> >What I'm doing right now, it doesn't make much of a diff either way, so
> >I'll use case sinces its less typing...
>
> So ... 'case' is more "DRY"?
>
It seems to me, that since I can't tell a real diffrence (I'll look into
the benchmarking bits later), I might as well use what seems the easiest
to expand as things go along.

Less to type in

case i
when arg,a
...
when arb,b
...

instead of
if i="arg" or i="a"

:)

Sean Surname

7/29/2007 7:44:00 AM

0

Phlip wrote:
> forgottenwizard wrote:
>
>> What kind of diffrences are there, effectivly, between case and a series
>> of if statements, like in this:
>
> Google for "premature optimization is the root of all evil".

Classify as "nostrum-emitting moron."
--
Posted via http://www.ruby-....

Kaldrenon

8/1/2007 6:29:00 PM

0

On Jul 29, 12:10 am, forgottenwizard <phrexianrea...@hushmail.com>
wrote:
> Less to type in
>
> case i
> when arg,a
> ...
> when arb,b
> ..
>
> instead of
> if i="arg" or i="a"
>
> :)

Just a thought from an iffer (cases are ugly in Java, so I just got
used to always iffing):

case i
when arg,a
...
when arb,b
...
end

isn't much different from

if [arg,a].include?( i )
...
elsif [arb,b].include?( i )
...
end

include? is possibly less efficient, though. Haven't benched it.