Multi-Interface Patch

[Brian Aker]

Hi!

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....

Cheers,
	-Brian

--
_______________________________________________________
Brian "Krow" Aker, brian at tangent.org
Seattle, Washington
http://krow.net/                     <-- Me
http://tangent.org/                <-- Software
http://exploitseattle.com/    <-- Fun
_______________________________________________________
You can't grep a dead tree.