After more discussion with Adam, it seems that making the Transaction object itself a movable type could alleviate all of these concerns about heap allocations, ownership, and lifetime. 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. Casey ----- Original Message ----- > Yes, if we can do that, that will be far more easier..I will double check > that if apply_transaction is been used from any of the performance sensitive > path and do the changes accordingly..Thanks.. > > -----Original Message----- > From: Samuel Just [mailto:sjust@xxxxxxxxxx] > Sent: Thursday, December 03, 2015 9:51 AM > To: Somnath Roy > Cc: Adam C. Emerson; Sage Weil; Samuel Just (sam.just@xxxxxxxxxxx); > ceph-devel@xxxxxxxxxxxxxxx > Subject: Re: queue_transaction interface + unique_ptr + performance > > As far as I know, there are no current users which want to use the > Transaction later. You could also change apply_transaction to copy the > Transaction into a unique_ptr since I don't think it's used in any > performance sensitive code paths. > -Sam > > On Thu, Dec 3, 2015 at 9:48 AM, Somnath Roy <Somnath.Roy@xxxxxxxxxxx> wrote: > > Yes, that we can do..But, in that case aren't we restricting user if they > > want to do something with this Transaction object later. I didn't go > > through each and every part of the code yet (which is huge) that are using > > these interfaces to understand if it is using Transaction object > > afterwards. > > > > Thanks & Regards > > Somnath > > -----Original Message----- > > From: Adam C. Emerson [mailto:aemerson@xxxxxxxxxx] > > Sent: Thursday, December 03, 2015 9:25 AM > > To: Somnath Roy > > Cc: Sage Weil; Samuel Just (sam.just@xxxxxxxxxxx); > > ceph-devel@xxxxxxxxxxxxxxx > > Subject: Re: queue_transaction interface + unique_ptr + performance > > > > On 03/12/2015, Somnath Roy wrote: > >> Yes, I posted the new result after adding -O2 in the compiler flag and it > >> shows almost no overhead with unique_ptr. > >> I will add the test of adding to list overhead and start implementing the > >> new interface. > >> But, regarding my other point of changing all the objecstore interfaces > >> (my first mail on this mail chain in case you have missed) taking > >> Transaction, any thought of that ? > >> Should we reconsider having two queue_transaction interface ? > > > > As I understand it, the concern with switching to unique_ptr was that the > > callee would move from the reference without this being known to the > > caller. > > > > Would it make sense to pass as an RValue reference (i.e. TransactionRef&&)? > > That way the compiler should demand that the callers explicitly use > > std::move on the reference they're holding, documenting at the site of the > > call that they're willing to give up ownership. > > > > > > -- > > Senior Software Engineer Red Hat Storage, Ann Arbor, MI, US > > IRC: Aemerson@{RedHat, OFTC, Freenode} > > 0x80F7544B90EDBFB9 E707 86BA 0C1B 62CC 152C 7C12 80F7 544B 90ED BFB9 > N�����r��y���b�X��ǧv�^�){.n�+���z�]z���{ay�ʇڙ�,j��f���h���z��w������j:+v���w�j�m��������zZ+��ݢj"�� -- 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
