Multi-Interface Patch

[Dustin Sallings]

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?

	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?

> UDP to met is best use for tiny things... once you go above a single  
> packet, you might as well be using TCP.

	Well, maybe.  It doesn't sound like that's how it's used, though.

> You will have to take a shot in the dark for array size, and then  
> realloc() for growth in the array.
>
> The memory allocations will kill any performance gain. Plus, for  
> embedding, its just not going to be that friendly to small client  
> libraries.

	alloca?

>> 	for res in responses:
>> 		char *key = key_map[res.opaque - start_opaque];
>
> Unless something changes, you won't know if all keys were retrieved  
> or not (aka you would have to fill up the network with NOT_FOUND  
> packets).

	You do, but not because you get the key names vs. opaque IDs.

> This assumes order as well (so you can't optimize the internals of  
> the server to just send keys as quickly as they are processed). You  
> create an
> implicit ORDER BY (yes... mentioning SQL). If you don't order...  
> well then you will need a hash or a double array. More memory, and  
> if array an array scan.

	I don't know why you think order should matter.  You define integers  
that map directly to array offsets.  In what order could you imagine  
receiving these where something more than subtraction is necessary?

> Array states, or hashes, are expensive.
>
> Unless someone else has a way to avoid he ordering, and the state  
> usage... this is going to turn out to be a lot slower then the text  
> protocol in the overall architecture.


	You're thinking about this in a way that I can't seem to be able to.

	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?

-- 
Dustin Sallings