• <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

            亚洲va久久久噜噜噜久久天堂| 国产精品视频久久久| 思思久久精品在热线热| 亚洲精品美女久久久久99| 青青草原综合久久大伊人精品| 午夜精品久久影院蜜桃| 国内精品久久久久影院优| 色偷偷91久久综合噜噜噜噜| 亚洲精品tv久久久久久久久| 亚洲国产成人久久综合一| 久久久久久国产a免费观看黄色大片| 久久国产亚洲精品无码| 欧洲国产伦久久久久久久| 久久精品国产亚洲一区二区| 国产美女亚洲精品久久久综合| 国产成人无码精品久久久免费| 伊人久久大香线蕉综合影院首页 | 亚洲国产天堂久久综合网站| 亚洲色大成网站www久久九| 少妇被又大又粗又爽毛片久久黑人| 久久人人爽人人爽人人AV| 中文字幕久久精品| 久久久久久久综合综合狠狠| 成人资源影音先锋久久资源网| 日韩精品久久久久久久电影蜜臀| 久久夜色精品国产| 久久久久亚洲av成人无码电影| 久久精品视频网| 久久99免费视频| 久久国产精品久久精品国产| 久久国产乱子精品免费女| AV狠狠色丁香婷婷综合久久| 老色鬼久久亚洲AV综合| 蜜臀久久99精品久久久久久小说| 亚洲欧美日韩久久精品第一区| 久久人做人爽一区二区三区| 亚洲欧美日韩精品久久亚洲区| 亚洲人AV永久一区二区三区久久| 无码任你躁久久久久久| 亚洲va中文字幕无码久久不卡| 欧美丰满熟妇BBB久久久|