Perl Client

Greg Whalin gwhalin at meetup.com
Sun Jul 2 20:55:10 UTC 2006


Starting to optimize perl language features (mentioned in this email) in 
the perl client seems to me to be a waste of time when it comes to 
optimization of a site/application.  I guess it has some benefit for 
fun, educational purposes, or just to improve benchmark scores but I 
just can't see the perl memcache client being a bottleneck in any real 
application.  Even if it were a bottleneck, slight language tweaks (such 
as removing "return undef") are unlikely to have any meaningful effect 
in code that has a bottleneck in network IO.

gw

Brad Fitzpatrick wrote:
> On Sun, 2 Jul 2006, Brian Moon wrote:
> 
>> Marcel Holan wrote:
>>> Hi,
>>>
>>> we haven't looked for a long time on Cache::Memcached (yeah the Perl Client), because it simply works
>>> for us. But of course one does not want to be potentionally inefficient, so
>>> before I'll have a look at the new Perl-Client (allegedly 2times as fast as
>>> Cache::Memcached on CPAN - but not according to your tests).
>>>
>>> Well I had a brief look at Cache::Memcached 1.18 on CPAN. Uuuuh - oooh....
>>>
>>> Clearly written way before the days of PBP.
>>> Clearly written by a Non-Perlie.
>>> Clearly improvable.
>>>
>>> Strange. I thought Tree::Nary (on CPAN) which we have re-written for our own
>>> use and lowered its space requirements by a factor of eight and improved its
>>> speed by a factor of 10-20 (depending on operation) was an exception.
>>>
>>> - Never use "return undef"
>>> - Never use for-push, use map instead
>>> - fields?
>>> - shift instead @_; $_[x] instead shift
>>> - ...
>>>
>> Well, I did not write the Perl client.  Um, I believe Danga (maybe even
>> Brad himself) did.
> 
> Yeah, me and Avva.
> 
>> Brad has spoken very kindly of other rewriting it to
>> be better and more efficient.
> 
> There are some slow paths in parsing that could be sped up, for sure, but
> most attempts to make it faster have thrown out the baby with the
> bathwater: they're really fast but don't handle any of the error
> conditions, some not even doing multi-server support.
> 
> Artur started writing the parsing in XS recently, but got sidetracked.
> 
> - Brad
> 



More information about the memcached mailing list