From: "Shot (Piotr Szotkowski)" <shot@...>
Date: 2009-11-18T16:04:32+09:00
Subject: Re: Looking for Set implementation in C

--V0207lvV8h4k8FAm
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 =E2=80=93 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 =3D 100): http://gist.github.com/237608

Hmmm, I wonder how the results would look with some Ruby Inline love.

> I am suspecting thought that differences might be caused by GC

perftools.rb (used to profile my code) have the vice that they=E2=80=99re
not really counting time spent in certain methods, but rather every
now and then (by default 100 times a second) poll the process for
the current stacktrace and do a statistic analysis afterwards:
http://github.com/tmm1/perftools.rb

There are two virtues of this approach, though: first, the profiling is
external to the running process and does not impact it (in particular,
does not slow the process down, nor alter the relative method execution
times); second, GC is counted separately.

I=E2=80=99ll see what perftools.rb show for the benched cases.

> because I cannot see a clear pattern and in some cases MySet is faster
> than Hash with each_key which technically cannot be the case because
> one calls the other.

In my runs MySet#each is consistently faster than Hash#each_key in the
=E2=80=98large=E2=80=99 benches (small numbers of iterations over larger en=
ums) and
consistently slower in the =E2=80=98small=E2=80=99 benches (large numbers o=
f iterations
over smaller enums) =E2=80=93 and this is after re-running the benchmark wi=
th
GC.disable.

Interestingly, while in the =E2=80=98real=E2=80=99 part of the benchmarks 1=
=2E9 is
generally faster than of 1.8, the =E2=80=98rehearsal=E2=80=99 stage is some=
times
slower in 1.9. I=E2=80=99m 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).

=E2=80=94 Shot
--=20
I=E2=80=99ve got an inferiority complex, but it=E2=80=99s not very good.

--V0207lvV8h4k8FAm
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAksDnHsACgkQi/mCfdEo8UovuQCgkGZoa2fP3MFnuJKal8mBMkrQ
YCIAoJW3klaQmAtEwOKVNg1HKsDqNcR/
=5YZu
-----END PGP SIGNATURE-----

--V0207lvV8h4k8FAm--