Multi-Interface Patch

Dustin Sallings dustin at spy.net
Fri Feb 15 08:18:22 UTC 2008


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





More information about the memcached mailing list