From: Eric Hodel <drbrain@...7.net>
Date: 2007-07-18T05:45:25+09:00
Subject: Re: memcache C extension

On Jul 17, 2007, at 12:45, snacktime wrote:

> I've decided I want to become more proficient in C, so the project is
> chose is a ruby memcache C extension.  I found the following site with
> a hash algorithm that seems to be an improvement on the default on,
> can anyone think of a reason why not to use this?
>
> http://www.last.fm/user/RJ/journal/2007/04/10/392555/

A consistent hashing library is completely orthogonal from a  
memcached library.

You'd be better off wrapping apr_memcache or libmemcache than writing  
yet another C memcached client.

> Also, since the extension isn't going to be thread safe (I'd have to
> create a new native thread for each instance of the class I think if I
> wanted to do that),  I was thinking about the best way to structure it
> would be to use global variables for the C struct's that can only be
> created once.    Then in the initialize function I can make sure to
> only call the C function mc_new() once.

Only one thread can be in C code at a time (unless you call  
rb_thread_select), so writing ruby-thread-safe C libraries is  
probably easier than you suspect.

> Also, I have a particular need for caching database queries, where
> buffer the returned rows and then send the whole thing to memcache.
> Would it be more efficient to implement a string buffer in C rather
> then use an array or concating strings in ruby?  I'm thinking about
> adding this as an additional feature, where you create a buffer, fill
> it up, then when you want to do a memcache add/set, you tell it to
> add/set the contents of the buffer.

It will be a better use of your time to use an existing memcached  
library and optimize your entire task using benchmarks and  
profiling.  memcached overhead is probably not going to be your  
bottleneck.

--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars