perl client status
brad at danga.com
Mon Jul 17 21:08:25 UTC 2006
Quick update on status of Perl memcached client, since people are talking
about it a lot and I'm about to go out of town.
Here are some recent tags/branches:
1.18 is the latest thing on CPAN. Its parsing code isn't fast, but worse:
it's not profiable with any of the good tools. (DProf, Devel::Profiler,
SmallProf all choke on it because of some things it does with
1.18-but-profilable is as its named: 1.18 with nasty tricks removed, so
all profilers work again. It revealed the same thing I saw ages ago and
is already in the comments: parsing responses to gets is slow.
Trunk now has the parsing code split off into its own class/object.
Performance is about the same (maybe a little worse), but the code is
incredibly readable now in comparison, and the new GetParser class was
designed to be rewritten in C (XS). All the variables/state you need are
in the parser class, and the object backing is an arrayref, to make it
even easier/faster from XS.
Also note the dev/bench.pl script in profilable/trunk. Just use it with
'time' to see how long 3,000 mixed-size multi-gets take.
If anybody wants to write an XS GetParser, I'll be out of town until
August 1st, so happy hacking!
Wrap $FOO instead!
No. I much prefer the flexibility of Perl and its
production-tested error handling. I only believe in writing the hot
paths in C, not everything. Leads to inflexibility and bugs.
Can $FOO become the new Cache::Memcached?
No. See above.
But $FOO is so much faster.
Okay. Does it do multi-server, error handling, parallized requests,
Basically, I'm going to be stubborn about this. Make the slow parts
optionally fast, but don't rewrite it all.
If nobody gets around to this, I'll do it when I get back, sometime.
More information about the memcached