Performance diffrence between ifs and case

On Mon, 30 Jul 2007, Alex Y. wrote:

Write it up here…
http://rubygarden.org/ruby/page/show/RubyOptimization
…the wiki page where I keep breadcrumbs of info for when desperation
requires me to shovel perfectly correct nostrums to one side and put in a
twist of speed.

Speaking of which… Rubygarden seems to be slow…
Too slow for me to write this up, as a matter of fact.

John C. Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : [email protected]
New Zealand

On Jul 30, 2007, at 9:35 AM, Alex Y. wrote:

Gregory B. wrote:

On 7/30/07, Alex Y. [email protected] wrote:

Benchmark.bmbm(20) do |x|
x.report(“if”){for i in 0…1000000 do
Yuck!
1000000.times do … end
Meh.

It has nothing to do with timing. It’s about ugly verses pretty. :slight_smile:

James Edward G. II

John C. wrote:

http://rubygarden.org/Ruby/page/show/CaseIfBenchmark

Fab. Thanks for that - I wouldn’t have got round to it.

On 7/31/07, Paul [email protected] wrote:

range 0.657000 0.000000 0.657000 ( 0.656000)
times 0.609000 0.000000 0.609000 ( 0.609000)
each 0.594000 0.000000 0.594000 ( 0.594000)
----------------------------- total: 1.860000sec

     user     system      total        real

range 0.641000 0.000000 0.641000 ( 0.640000)
times 0.594000 0.000000 0.594000 ( 0.594000)
each 0.578000 0.000000 0.578000 ( 0.594000)

I’ll remember this next time I want to save 0.03 s per 1000000
iterations.

My original point was that if you want to do something n times, use
n.times
:slight_smile:

Gregory B. wrote:


I’ll remember this next time I want to save 0.03 s per 1000000 iterations.

My original point was that if you want to do something n times, use n.times
:slight_smile:

My point was going to be that the one place optimisation really matters
is in benchmark code - you only want to measure the effect you’re
looking for - but I managed to shoot myself in the foot and prove
another point. Don’t assume, measure! :slight_smile:

def nop
end

Benchmark.bmbm(20) do |x|
x.report(“range”){for i in 0…1000000 do nop end}
x.report(“times”){1000000.times do nop end}
x.report(“each”){(0…1000000).each do nop end}
end

range 0.657000 0.000000 0.657000 ( 0.656000)
times 0.609000 0.000000 0.609000 ( 0.609000)
each 0.594000 0.000000 0.594000 ( 0.594000)
----------------------------- total: 1.860000sec

     user     system      total        real

range 0.641000 0.000000 0.641000 ( 0.640000)
times 0.594000 0.000000 0.594000 ( 0.594000)
each 0.578000 0.000000 0.578000 ( 0.594000)

On Jul 29, 12:10 am, forgottenwizard [email protected]
wrote:

:slight_smile:

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.

On 8/1/07, Alex Y. [email protected] wrote:

My point was going to be that the one place optimisation really matters
is in benchmark code - you only want to measure the effect you’re
looking for - but I managed to shoot myself in the foot and prove
another point. Don’t assume, measure! :slight_smile:

If that’s the case you shouldn’t be making a nop() method call.
That’s a huge part of what you’re seeing there.

James Edward G. II wrote:

It has nothing to do with timing. It’s about ugly verses pretty. :slight_smile:
To be perfectly honest, I had it fixed in my head that for…in… was
faster than N.times {} when I wrote the original code, and was just
trying to get rid of an unnecessary overhead. Just shows what use
assumptions like that are…

Hi –

On Thu, 2 Aug 2007, Alex Y. wrote:

end

measure! :slight_smile:
Even if one of the iterators (each or times) was much faster than the
other, as long as you use the same one every time you’re controlling
for that. You just wouldn’t want to go back and forth.

David