By the way, is this patch going to be integrated in the mainline? I mean, I would understand the whole feature to be kicked out but if it kept in the official version, the opimized way to do things sounds better, no?
cheers, Jean-Charles On Jun 1, 8:57 pm, Trond Norbye <[email protected]> wrote: > On Jun 1, 2009, at 6:53 PM, Jean-Charles Redoutey wrote: > > > > > > > I kind of feel lonely on my topic ;-) > > Anyway, still in the same area, I've made prefix stats collection > > use the same pattern with per thread statistics and global > > aggregation on request. Those stats overhead shall then not be more > > than the other ones. > > Which by the way lead me to a question: > > Is it really useful to have per thread mutex? I mean, per > > construction, this is only updated from one thread at a time, isn't > > it? The only concurrent access is the global aggregation, in which > > case atomic primitives should work perfectly (also I do agree, there > > is nothing very portable :-( ), or even no locking at all could be a > > solution, I mean aggregation may not see the "right" values because > > of cache(s) and/or reordering stuffs but they would'nt be "so far" > > from the true, which is already what stats command are answering > > considering the thoughput usually going through memcached servers ... > > cheers, > > As they say: premature optimization is the root of all evil.. When we > moved the status to a thread-local scope we wanted to make the stats > "just as safe" as the old implementation, and optimize it later on if > it ever turned up as a performance problem in a benchmark.... > > Cheers, > > Trond
