[announce] php: mcache extension 1.0

[Sean Chittenden]

>>> Benchmarking libmemcache in c directly...
>>> Performed 40000 sets in 2.248915 seconds.
>>> Performed 40000 gets in 2.234578 seconds.
>>> Performed 20000 gets of 2 values at once in 1.205434 seconds.
>>
>> Anecdotally, I'd be interested in your tests of this against 1.2.1
>> given it has some logic to reduce CPU cycles on hashing when there is
>> only one server.  CRC32 is reasonably inexpensive, but avoiding it all
>> together is certainly cheaper.  :)  -sc
>>
>
> Actually, I was under the impression you introduced that optimization 
> in
> 1.2.0, in fact I checked, and the hashing is not being called with one
> server under 1.2.0.
>
> Here is the benchmark with 1.2.1 howerver:
> Benchmarking libmemcache in c directly...
> Performed 40000 sets in 2.213733 seconds.
> Performed 40000 gets in 2.144761 seconds.
> Performed 20000 gets of 2 values at once in 1.218654 seconds.
>
> As you can see, the gets where slightly faster (maybe not statistically
> significant though)... so maybe I'm missing something and the hash was
> getting called in 1.2.0.

Ah, ok.  I didn't see a version number in your post so I wasn't sure if 
you were on 1.1.0 given your prior statements on holding off on 1.2.0 
since you just started testing.  Very cool numbers, however.  Are you 
using mcm_req_add() or mcm_req_add_ref()?  I haven't looked yet.  You 
could reduce a strdup() by using mcm_req_add_ref() if you promise not 
to change the key during the duration of the request (ie, until you 
recycle memcache_req).  Between 1.2.0 and 1.2.1 I changed from using 
mcm_req_add() to mcm_req_add_ref() in mcm_aget(): you could likely do 
the same in your bindings.  -sc

-- 
Sean Chittenden