• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            Zero Lee的專欄

            The Return Value Optimization[2]

            ------->
            Without any optimization, the compile-generated(pseduo) code for Complex_Add() is

            ?1 void ?Complex_Add( const ?Complex & ?__tempResult,? const ?Complex & ?c1,? const ?Complex & ?c2)
            ?2
            {
            ?3 ??? struct
            ?Complex?retVal;
            ?4 ???retVal.Complex::Complex();? // ?Constructor?retval

            ?5 ???retVal.real? = ?a.real? + ?b.real;
            ?6 ???retVal.imag? = ?a.imag? +
            ?b.imag;
            ?7 ???__tempResult.Complex::Complex(retVal);? // ?copy-constructor

            ?8 ??retVal.Complex:: ~ Complex();? // ?destroy?retVal
            ?9 ?? return ;
            10 }
            The compiler can optimize Complex_Add() by eliminating the local object retVal and replacing it with __tempResult. This is the Return Value Optimization:
            1 void ?Complex_Add( const ?Complex & ?__tempResult,? const ?Complex & ?c1,? const ?Complex & ?c2)
            2
            {
            3 ???__tempResult.Complex::Complex();?? // ?construcotr?__tempResult

            4 ???__tempResult.real? = ?a.real? + ?b.real;
            5 ???__tempResult.imag? = ?a.imag? +
            ?b.imag;
            6 ??? return
            ;
            7 }
            The RVO eliminated the local retVal object and therefore saved us a constructor as well as a destructor computation.
            To get a numerical feel for all this efficiency discussion, we measured the impact of RVO on execution speed. We coded two versions of operator +(), one of which was optimized and the other not. The measured code consisted of a million loop iterations:
            ?1 int ?main()
            ?2
            {
            ?3 ???Complex?a( 1 , 0
            );
            ?4 ???Complex?b( 2 , 0
            );
            ?5
            ???Complex?c;
            ?6 ??? // ?begin?timing?here

            ?7 ??? for ?( int ?i? = ? 1000000 ;?i? > ? 0 ;? -- i)? {
            ?8 ??????c? = ?a? +
            ?b;
            ?9 ???}

            10 ??? // ?stoping?timing?here
            11 }
            The second version, without RVO, executed in 1.89 seconds. The first version, with RVO applied was much faster --1.30 seconds.

            Compiler optimizations, naturally, must preserve the correctness of the original computation. In the case of the RVO, this is not always easy. Since the RVO is not mandatory, the compiler will not perform it on comlicated functions. For example, if the function has multiple return statements returning objects of different names, RVO will not be applied. You must return the same named object to have a chance at the RVO.
            One compiler we tested refused to apply the RVO to this particular version of operator +:
            1Complex?operator?+(const?Complex&?a,?const?Complex&?b)
            2{
            3???//?operator?+?version?1
            4???Complex?retVal;
            5???retVal.real?=?a.real?+?b.real;
            6???retVal.imag?=?a.imag?+?b.imag;
            7???return?retVal;
            8}
            It did, however, apply the RVO to this version:
            1Complex?operator?+(const?Complex&?a,?const?Complex&?b)
            2{
            3???//?operator?+?version?2
            4???double?r?=?a.real?+?b.real;
            5???double?i?=?a.imag?+?b.imag;
            6???return?Complex(r,?i);
            7}

            8???
            We speculated that the difference may lie in the fact that Version 1 used a named variable(retVal) as a return value whereas Version 2 used an unnamed variable. Version 2 used a constructor call in the return statement but never named it. It may be the case that this particular compiler implementation chose to avoid optimizing away named variables.
            Our speculation was boosted by some additional evidence. We tested two more versions of operator +:
            ?1Complex?operator?+(const?Complex&?a,?const?Complex&?b)
            ?2{
            ?3???//?operator?+?version?3
            ?4???Complex?retVal(a.real?+?b.real,?a.imag?+?b.imag);
            ?5???return?retVal;
            ?6}

            ?7and
            ?8Complex?operator?+(const?Complex&?a,?const?Complex&?b)
            ?9{
            10???//?operator?+?version?4
            11???return?Complex(a.real?+?b.real,?a.imag?+?b.imag);
            12}
            As speculated, the RVO was applied to Version 4 but not to Version 3.
            In addition, you must also define a copy constructor to "Turn on" the Return Value Optimization. If the class involved does not have a copy constructor defined, the RVO is quietly turned off.

            Key Points:
            [1] If you?must return an object by value, the Return Value Optimization will help performance by eliminating the nedd for creation and destruction of a local object.

            [2] The application of the RVO is up to the direction of the compiler implementation. You need to consult your compile documentation or experiment to find if and when RVO is applied.

            [3] You will have a better shot at RVO by deploying the computational constructor.

            posted on 2006-11-13 19:36 Zero Lee 閱讀(306) 評論(0)  編輯 收藏 引用 所屬分類: C++ Performance

            久久伊人精品青青草原高清| 久久99久国产麻精品66| 精品免费久久久久国产一区| 久久久久这里只有精品| 久久精品aⅴ无码中文字字幕不卡| 性欧美大战久久久久久久久| 精品久久久久久无码中文字幕 | 久久国产精品无码HDAV | 久久久久亚洲精品中文字幕| 亚洲AV成人无码久久精品老人| 久久精品不卡| 国产精品久久久久久久久鸭| 久久久久亚洲av成人网人人软件| 51久久夜色精品国产| 久久人人爽人人爽人人片av高请| 久久久久九国产精品| 久久九九亚洲精品| 亚洲色欲久久久综合网东京热| 久久亚洲中文字幕精品一区| 久久国产免费观看精品| 久久久久久国产精品无码超碰| 久久综合五月丁香久久激情| 亚洲天堂久久精品| 成人国内精品久久久久影院| 伊人久久精品无码二区麻豆| 伊人久久大香线蕉无码麻豆| 久久人人爽人人爽人人片AV麻豆| 久久青青草原综合伊人| 97精品伊人久久大香线蕉app| A级毛片无码久久精品免费| 亚洲综合久久夜AV | 免费一级欧美大片久久网| 国产精品无码久久久久| 99久久国产综合精品成人影院| 久久99精品国产| 久久噜噜电影你懂的| 97久久综合精品久久久综合| 日韩人妻无码精品久久久不卡| 亚洲色欲久久久综合网| 99久久免费国产精品特黄| 7国产欧美日韩综合天堂中文久久久久|