From: Robert Klemme <shortcutter@...>
Date: 2009-11-18T17:10:26+09:00
Subject: Re: Looking for Set implementation in C

2009/11/18 Shot (Piotr Szotkowski) <shot@hot.pl>:
> Robert Klemme:
>
>> 2009/11/16 Shot (Piotr Szotkowski) <shot@hot.pl>:
>
>>> My initial performance tests (with the very nice perftools.rb gem from
>>> Aman Gupta) seem to suggest that I spend most of the time in (C-based)
>>> Hash#each_key, mostly due to calls from Set#each – but it looks like
>>> the Set#each calls themselves add a significant overhead.
>
>> Interestingly that does not need to be
>> the case. Try out the attached test.
>
> Thanks so much for the thorough tests! The results on my machine do
> look interesting (benched both MRI 1.8 and 1.9, and did another run
> with SMALL = 100): http://gist.github.com/237608

You're welcome!

> In my runs MySet#each is consistently faster than Hash#each_key in the
> ‘large’ benches (small numbers of iterations over larger enums) and
> consistently slower in the ‘small’ benches (large numbers of iterations
> over smaller enums) – and this is after re-running the benchmark with
> GC.disable.

This is suspicious.  The only explanation I have right now is that
this is an artifact of the sampling process which is not accurate
(similar as with Java's -Xrunhprof:cpu=samples).

> Interestingly, while in the ‘real’ part of the benchmarks 1.9 is
> generally faster than of 1.8, the ‘rehearsal’ stage is sometimes
> slower in 1.9. I’m wondering how does this translate to my case,
> where I might have quite a few short-lived, one-time Sets (though
> I probably should pull the instantiations code into the benchmark
> to simulate my this case before making any guesses at it).

Yet another interesting question. :-)  The tests should of course
mimic the real world case as closely as possible.

Thanks for the interesting discussion.

Kind regards

robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/