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


 

Forums >

comp.lang.ruby

disabling method caching

Maarten Boonen

1/21/2005 7:21:00 PM

Hi,

I am trying to compare a few algorithms, but there's a rather
substantial difference in speed when I run a program like following 5
times,

start = Time.now
algo(params)
puts Time.now - start

or when I do

5.times do
start = Time.now
algo(params)
puts Time.now - start
end

(especially if I already called algo() previously, with different
parameters)

I suspect this has to do with method caching. Is this correct? If so, is
there a way to disable it? Or are there better ways of comparing?

Any help will be greatly appreciated.

Thanks in advance,

Maarten
4 Answers

Simon Strandgaard

1/21/2005 10:03:00 PM

0

On Sat, 22 Jan 2005 04:20:57 +0900, Maarten Boonen <m44rt3n@yahoo.com> wrote:
> I am trying to compare a few algorithms, but there's a rather
> substantial difference in speed when I run a program like following 5
> times,
[snip]

5 times is not enough to tell how much time that average is spend in
the code.. it usually takes time to do setup/teardown, it can be
affected by the operating systems scheduler.

The average running time usually becomes visible by running it many times..
over and over.. try with 1000 times.. so that the program spends some seconds
in the code.

Tell me if it helps.

> I suspect this has to do with method caching. Is this correct? If so, is
> there a way to disable it? Or are there better ways of comparing?

I don't think such thing exists. sorry.

--
Simon Strandgaard

Alexey Verkhovsky

1/21/2005 10:22:00 PM

0

Simon Strandgaard wrote:

>The average running time usually becomes visible by running it many times..
>over and over.. try with 1000 times.. so that the program spends some seconds
>in the code.
>
>
It's sometimes a good idea, when profiling something, to execute it once
and _then_ start recording the profiling information.
There can be all sorts of lazy instantiation on the first pass, that
complicates profiling information unnecessarily, and sometimes may throw
you completely off the right track.

Either that or run it roughly speaking 100 times longer than _the first_
pass takes to process.

Unless you are interested in the startup performance, of course. :)

--
Best regards,

Alexey Verkhovsky

Ruby Forum: http://ruby... (moderator)
RForum: http://rforum.and... (co-author)
Instiki: http://i... (maintainer)

Maarten Boonen

1/21/2005 10:44:00 PM

0

Simon Strandgaard schreef:
> 5 times is not enough to tell how much time that average is spend in
> the code.. it usually takes time to do setup/teardown, it can be
> affected by the operating systems scheduler.
>
> The average running time usually becomes visible by running it many times..
> over and over.. try with 1000 times.. so that the program spends some seconds
> in the code.

well, the total testing already takes half an hour, so doing it 1000
times isn't really an option. But I'm pretty sure that's not the
problem. Some example code might clarify:

if I do

[250].each do |sg|

5.times do

start = Time.now
algorithm(sg)
puts Time.now - start

end

end

the times are (in seconds):

8.853
8.602
7.33
7.281
7.32

but if I do

[1,250].each do |sg|

5.times do

start = Time.now
algorithm(sg)
puts Time.now - start

end

end

the times are (for the 250 case):

2.804
4.336
3.835
4.036
3.765

> I don't think such thing exists. sorry.


Thanks anyway,

Maarten

Robert Klemme

1/22/2005 2:31:00 PM

0


"Maarten Boonen" <m44rt3n@yahoo.com> schrieb im Newsbeitrag
news:1106347442.809679@seven.kulnet.kuleuven.ac.be...
> Simon Strandgaard schreef:
>> 5 times is not enough to tell how much time that average is spend in
>> the code.. it usually takes time to do setup/teardown, it can be
>> affected by the operating systems scheduler.
>>
>> The average running time usually becomes visible by running it many
>> times.. over and over.. try with 1000 times.. so that the program spends
>> some seconds
>> in the code.
>
> well, the total testing already takes half an hour, so doing it 1000 times
> isn't really an option. But I'm pretty sure that's not the problem. Some
> example code might clarify:
>
> if I do
>
> [250].each do |sg|
>
> 5.times do
>
> start = Time.now algorithm(sg) puts Time.now - start
> end
>
> end
>
> the times are (in seconds):
>
> 8.853
> 8.602
> 7.33
> 7.281
> 7.32
>
> but if I do
>
> [1,250].each do |sg|
>
> 5.times do
>
> start = Time.now algorithm(sg) puts Time.now - start
> end
>
> end
>
> the times are (for the 250 case):
>
> 2.804
> 4.336
> 3.835
> 4.036
> 3.765

With a straightforward definition of something that simply takes time, I
don't see any significant difference:

>> def algorithm(x) 100000.times {} end
=> nil
>> [250].each do |sg|
?> 5.times do
?> start = Time.now
>> algorithm(sg)
>> puts Time.now - start
>> end
>> end
0.029
0.028
0.028
0.031
0.027
=> [250]
>> [1,250].each do |sg|
?> 5.times do
?> start = Time.now
>> algorithm(sg)
>> puts Time.now - start
>> end
>> end
0.03
0.028
0.029
0.027
0.029
0.029
0.027
0.035
0.03
0.029
=> [1, 250]

I guess this cannot be answered without closer inspection of algorithm.
What exactly does it?

Regards

robert