Well, yeah we are, it's just the actual Transaction structure which wouldn't be dynamic -- the buffers and many other fields would still hit the allocator. -Sam On Thu, Dec 3, 2015 at 11:29 AM, Casey Bodley <cbodley@xxxxxxxxxx> wrote: > > ----- Original Message ----- >> Eh, Sage had a point that Transaction has a bunch of little fields >> which would have to be filled in -- its move constructor would be less >> trivial than unique_ptr's. >> -Sam > > It's true that the move ctor has to do work. I counted 18 fields, half of > which are integers, and the rest have move ctors themselves. But the cpu > is good at integers. The win here is that you're not hitting the allocator > in the fast path. > > Casey > >> >> On Thu, Dec 3, 2015 at 11:12 AM, Adam C. Emerson <aemerson@xxxxxxxxxx> wrote: >> > On 03/12/2015, Casey Bodley wrote: >> > [snip] >> >> The queue_transactions() interface could take a container of Transactions, >> >> rather than pointers to Transactions, and the ObjectStore would move them >> >> out of the container into whatever representation it prefers. >> > [snip] >> > >> > Or a pointer and count (or we could steal array_view from GSL). That way we >> > could pass in any continguous range (std::vector or even a std::array or >> > regular C style array allocated on the stack.) >> -- >> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
