Toru Maesaka wrote:
oops, clicked send before I finished the email :(
ASFAIK, Trond and Matt has been experimenting quite a bit with what
I've mentioned above.
True, more Trond than I. I've been working on a method of testing, and
have a good workload generator. We're actually not using mmap() at the
moment but we'd talked about it before. I don't think it would be a
complex change.
Also, Trond had some thoughts on how to do this with less locking which
he'd sketched out, but hasn't told me about yet. I think he was working
on resynching everything with the latest engine code.
- Matt
On Sat, Dec 20, 2008 at 9:42 PM, Toru Maesaka <[email protected]> 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,
