Multi-Interface Patch

[Brian Aker]

Hi!

On Feb 14, 2008, at 8:23 AM, Dustin Sallings wrote:

> On Feb 13, 2008, at 18:19, Brian Aker wrote:
>
>> The array is going to cost memory allocation though, and then a  
>> lookup to get my hands on it (which will be a scan on an array).
>
> 	Aren't you allocating memory when you read results?

Just once for the result buffer unless someone wants to be give the  
value free and clear. This allows other languages to do just their own  
copy.
The goal is process, and move on.

> 	How do you figure there's a scan on the array?  You should be able  
> to compute an exact array offset with subtraction.
> 	Moreover, your multiget request is already an array of something  
> isn't it?  Would it be possible to just use that?

No, you just build up the "get ..." and push it into the pipe as  
required out of the read buffer. No reason to know where a key came  
from.

As to order, memcached has to feed you keys back in the order you sent  
them, or you have to keep a map of key to opaque ID. That map is  
expensive. Dormando is saying that the end user should keep this, but  
you believe it belongs in the library.

I agree with you in that the library should handle this... why would  
an end user application want to have to track multiple keys? And  
inside of the library there is no reason either.

24 bytes of opaque vs at max 250 bytes? Just give me the keys, the  
indirection around opaque to me is more complicated then it is worth.

So right now... the only solution I see is to hide opaque and force  
key and data into the same field. That is the only way I can see to  
get around all of the extra memory allocation and object mapping. This  
is going to kill client interoperability though (or you can come up  
with a mapping to be compatible).

Another option, why not just make the server respond with keys if the  
client requests it?

> 	You get a list of keys and want to ask the server for them.  If  
> it's an array, you need a single integer to mark the beginning and  
> another to mark the end (noop result).
> 	When a response comes in, you validate it's not the end, and then  
> get the key from input[opaque - start_opaque] .  Is it more  
> complicated than that?


Yes, you are assuming that the server will respond with a bunch of NOT  
FOUND, and it will have to keep all keys in order of sent. Long term  
that is a bad idea (lots of processors should mean threads just  
feeding the return socket as fast as they get items eventually.

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.