----- Original Message ----- > 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 Sure. I was looking specifically at the tradeoffs between allocating and moving the Transaction object itself. As it currently stands, the caller of ObjectStore can choose whether to allocate its Transactions on the heap, embed them in other objects, or put them on the stack for use with apply_transactions(). Switching to an interface built around unique_ptr forces all callers to use the heap. I'm advocating for an interface that doesn't. Casey > > 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 > -- 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
