On Feb 14, 2008, at 23:34, Brian Aker wrote:
To me the creation of that array is pretty expensive. It is going to
be a system call (or series of system calls).
Yeah, but in your API in mget, you've already got it.
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.
I am starting to see your point... but it seems like a lot of effort
for not a lot of gain. The evidence that I might need is proof that
this is going to make a difference in performance. The two mallocs
(well... perhaps one if I screw around with a single memory block)
are expensive. Plus it means bloat in the driver for memory size
(something I have been trying to keep down).
So, I'll commit to creating a branch on this and seeing how
performance works out, and putting in the memory allocations.
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'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. :)
Thanks for arguing with me over this.
Hey...it's what I do. :)
--
Dustin Sallings
