brian at tangent.org
Thu Feb 14 07:02:50 UTC 2008
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
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
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.
Brian "Krow" Aker, brian at tangent.org
http://krow.net/ <-- Me
http://tangent.org/ <-- Software
http://exploitseattle.com/ <-- Fun
You can't grep a dead tree.
More information about the memcached