On 12/20/08 4:42 AM, "Toru Maesaka" <tmaes...@gmail.com> wrote:
Hi! I've quickly glanced through the repo and even though I think the idea of the flat allocator is neat and how it uses mmap (/me loves mmap), I think the flat allocator itself should belong outside the codebase. So, what I'm trying to say is, shouldn't this be a separate storage engine? Trond and I are currently experimenting on reshaping the codebase by changing the item structure to be a minimal and generic 32/64bit aligned structure, which the storage engine will handle. If you're interested I can write more about this. So what I'd like to know is, what exactly is it that you guys are concerned about dynamic linking at startup? If the performance loss (if we could even call it that) is going to become a huge issue for the memcached userbase, we could discuss/plan static linking too. Personally, I think working on things like improving memcached's space efficiency (more bang for buck) seem more important than the dynamic linking issue. Cheers, Toru Opinions? ASFAIK, It could be a separate storage engine, but not as spec'ed. The external storage engine specification does not allow for scatter-gather storage of the key and data. Thanks, Tony
