Hi --

On Thu, 2 Aug 2007, Alex Young wrote:

> Gregory Brown wrote:
>> On 7/31/07, Paul <Paul.McArdles / gmail.com> wrote:
>>> 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)
>> 
>> I'll remember this next time I want to save 0.03 s per 1000000 iterations.
>> 
>> <groans>
>> 
>> My original point was that if you want to do something n times, use n.times
>> :)
>> 
> 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!  :-)

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

-- 
* Books:
   RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242)
   RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
     & consulting:  Ruby Power and Light, LLC (http://www.rubypal.com)