Multi-Interface Patch

Brian Aker brian at
Fri Feb 15 08:24:39 UTC 2008


On Feb 15, 2008, at 1:48 PM, Dustin Sallings wrote:

> On Feb 14, 2008, at 23:34, Brian Aker wrote:
>> Right, but I am going to have to malloc the keys and lengths. I  
>> have no idea if the user still has that structure around during a  
>> fetch. There is no requirement that you have to stay in scope of  
>> the memcached_mget(). A user can call that, and lazily grab values  
>> as they want them.
> 	Are you saying you have to malloc them because the caller can free  
> them after the call to this function?  Perhaps I've been spending  
> too much time in languages with GCs and ref counts.

Exactly, this is what I have been trying to avoid :)

A large key list is N*C + N*8

> 	Well, we can certainly try it both ways and see what the difference  
> is.  If you can hang onto that char **keys, then it's absolutely got  
> to be cheaper.  There's less traffic (OK, negligibly), and you don't  
> have to copy and null terminate a key.

I keep thinking that the malloc really is going to hurt more then the  
network traffic. I do though like the idea that you can get a list of  
keys at the end which were never found.

> 	I'll gladly help you with the server if you want to benchmark it  
> both ways.  I'm convinced there's some kind of creativity that can  
> be applied to make the current way really fast, though.  :)

Ok. I mainly need to finish memslap so that I can do this easily.

One thing that is still missing though, is a means to get the binary  
port number... we will always know that the text port exists... Hmmm....


Brian "Krow" Aker, brian at
Seattle, Washington                     <-- Me                <-- Software    <-- Fun
You can't grep a dead tree.

More information about the memcached mailing list