RE: queue_transaction interface + unique_ptr + performance

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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��������+%������w��{.n����z��u���ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f




[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux