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
