◀Unicode版開発トップへ
  • 79 速度測定
    • 90 Re:速度測定
      • 156 Re2:速度測定
        • 157 Re3:速度測定
          • 158 Re4:速度測定
            • 159 Re5:速度測定
              • 160 Re6:速度測定
                • 161 Re7:速度測定
    • 93 Re:速度測定

  • [79] 速度測定 げんた 2007年12月01日 12:34

    CRunningTimer使用時のコンパイルエラーを修正するパッチを出しました．
    PatchUnicode#1842107

    TCHARで作り直した方がよいのでしょうかね．

    ちなみに速度測定結果ですが，CLayoutMgr::DoLayout()が妙に遅いです．
    ANSI: 46msec -> Unicode: 1297msec

    もう少し計測点を増やして原因を追った方がいいかも．

    [ANSI]
    1:"CDocLineMgr::ReadFile" : Enter
    1:"CDocLineMgr::ReadFile", 31㍉秒 : Exit Scope
    1:"CLayoutMgr::SetLayoutInfo" : Enter
    2:"CLayoutMgr::DoLayout" : Enter
    2:"CLayoutMgr::DoLayout", 46㍉秒 : Exit Scope
    1:"CLayoutMgr::SetLayoutInfo", 62㍉秒 : Exit Scope
    1:"CEditView::OnPaint" : Enter
    2:"CEditView::DispLineNew" : Enter
    2:"CEditView::DispLineNew", 0㍉秒 : Exit Scope
    1:"CEditView::OnPaint", 16㍉秒 : Exit Scope
    1:"CEditView::OnPaint" : Enter
    2:"CEditView::DispLineNew" : Enter
    2:"CEditView::DispLineNew", 0㍉秒 : Exit Scope
    1:"CEditView::OnPaint", 16㍉秒 : Exit Scope
    1:"CEditView::OnPaint", 172㍉秒 : Exit Scope

    [UNICODE]
    1:"CDocLineMgr::ReadFile" : Enter
    1:"CDocLineMgr::ReadFile", 62㍉秒 : Exit Scope
    1:"CLayoutMgr::SetLayoutInfo" : Enter
    2:"CLayoutMgr::DoLayout" : Enter
    2:"CLayoutMgr::DoLayout", 1297㍉秒 : Exit Scope
    1:"CLayoutMgr::SetLayoutInfo", 1328㍉秒 : Exit Scope
    1:"CEditView::OnPaint" : Enter
    2:"CEditView::DispLineNew" : Enter
    2:"CEditView::DispLineNew", 16㍉秒 : Exit Scope
    1:"CEditView::OnPaint", 16㍉秒 : Exit Scope
    1:"CEditView::OnPaint" : Enter
    2:"CEditView::DispLineNew" : Enter
    2:"CEditView::DispLineNew", 0㍉秒 : Exit Scope
    1:"CEditView::OnPaint", 0㍉秒 : Exit Scope
    1:"CEditView::OnPaint" : Enter
    1:"CEditView::OnPaint", 203㍉秒 : Exit Scope

    • [90] Re:速度測定 kobake 2007年12月06日 01:13

      確信犯的に遅くなる要因が2つあります。

      ・TextOut系のAPIを呼ぶ毎にダミーのSetPixelを呼んでいる (デバッグビルド時のみ)。
      　(理由)
      　ステップ実行時に、TextOut系のAPIを呼んだだけだと、見た目に反映されないことがある。
      　SetPixelを呼ぶことによって、それまでの描画APIの結果が即反映される性質を利用し、デバッグをしやすくしている
      　(今後)
      　config/build_config.h 内の定数定義で、SetPixelを呼ぶ／呼ばないを制御させる予定です。

      ・初回の文字幅取得時に、けっこうガッツリ計算をしまくってる
      　(挙動)
      　既に計算が済んだ (キャッシュが準備された) 文字の幅を取得する際には、
      　負荷はほとんど生じません。
      　(今後)
      　この「ガッツリっぷり」はまだまだ改善の余地があるので、今後修正します。
      　コントロールプロセスの共有メモリ側にキャッシュを置くのが理想な気がします。

      DoLayoutが劇的に遅いのは、たぶん上に挙げた要因のうち、後者の影響だと思います。
      さすがに「1秒」かかるのは許せませんねぇ。
      「止まらない (落ちない) から良いや」程度に考えていて後回しにしてましたが、
      割と近いうちに対応したいと思います。

      • [156] Re2:速度測定 ryoji 2008年02月25日 20:14

        ▼ kobakeさん
        > ・初回の文字幅取得時に、けっこうガッツリ計算をしまくってる
        > 　(挙動)
        > 　既に計算が済んだ (キャッシュが準備された) 文字の幅を取得する際には、
        > 　負荷はほとんど生じません。
        > 　(今後)
        > 　この「ガッツリっぷり」はまだまだ改善の余地があるので、今後修正します。

        もう着手されているかもしれませんが．．．
        動的文字幅計算の部分での無駄をちょっと省いてみました。
        そこそこ速くなった気がします。
        →PatchUnicode#1901281

        • [157] Re3:速度測定 kobake 2008年02月25日 20:36

          ▼ ryojiさん
          > ▼ kobakeさん
          > > ・初回の文字幅取得時に、けっこうガッツリ計算をしまくってる
          > > 　(挙動)
          > > 　既に計算が済んだ (キャッシュが準備された) 文字の幅を取得する際には、
          > > 　負荷はほとんど生じません。
          > > 　(今後)
          > > 　この「ガッツリっぷり」はまだまだ改善の余地があるので、今後修正します。
          >
          > もう着手されているかもしれませんが．．．
          > 動的文字幅計算の部分での無駄をちょっと省いてみました。
          > そこそこ速くなった気がします。
          > →PatchUnicode#1901281

          ご対応ありがとうございます。

          ちょっと自分ではテストする余力が無いので、
          テストする方にお願いしたいのですが、

          パッチ適用した状態で、
          http://mofmof.nsf.tc/soft/wforum/wforum.cgi?mode=allread&no=34
          「10. JIS範囲外の文字が多数あるファイルの読み込みでおかしくなる」
          この問題が発生しないこともテストしていただきたいです。

          Sourceforge側コメントによると、
          ＞周辺256文字をまとめて計算する
          ＞のもやめています。
          とのことですが、周辺256文字をまとめて計算しているのは
          上記10番バグに対応するためだったので。

          たしかそのときは GetDC, ReleaseDC が連呼されているせいで
          描画が崩れていたと記憶しています。

          • [158] Re4:速度測定 ryoji 2008年02月25日 20:52

            ▼ kobakeさん
            > たしかそのときは GetDC, ReleaseDC が連呼されているせいで
            > 描画が崩れていたと記憶しています。

            書き忘れましたが、元のソースでは関数が呼ばれるたびにフォントをCreateしまくっていて、いっさいDeleteObjectしていないようでした。
            リソースリークでパンクしていたということは無いでしょうか？
            今回のパッチでは起動時に１度フォント作成するだけなので、上記のことが原因なら大丈夫だと思いますが．．．

            ＃メニューやツールバーが黒くなったり表示されなくなるというのはリソースリークの典型的な症状じゃないかしら

            • [159] Re5:速度測定 kobake 2008年02月25日 21:24

              ▼ ryojiさん
              > ▼ kobakeさん
              > > たしかそのときは GetDC, ReleaseDC が連呼されているせいで
              > > 描画が崩れていたと記憶しています。
              >
              > 書き忘れましたが、元のソースでは関数が呼ばれるたびにフォントをCreateしまくっていて、いっさいDeleteObjectしていないようでした。
              > リソースリークでパンクしていたということは無いでしょうか？
              > 今回のパッチでは起動時に１度フォント作成するだけなので、上記のことが原因なら大丈夫だと思いますが．．．

              なるほどっ！ぜんぜん気づいてませんでした。
              そっちが原因っぽいですね。
              失礼致しました。
              今回のパッチで速度向上に加えてリソースリーク修正、となりそうです。

              • [160] Re6:速度測定 ryoji 2008年02月28日 00:28

                ▼ kobakeさん
                > なるほどっ！ぜんぜん気づいてませんでした。
                > そっちが原因っぽいですね。
                CJK統合漢字（U+4E00 ～ U+9FA5）すべてを含むファイルで自己確認してみました。
                従来コードで１文字づつ判定させるようにした場合（旧版相当）は問題の現象が見られましたが、パッチ適用版では問題ありませんでした。
                ちなみに、タスクマネージャでGDIオブジェクト数を見ると、パッチ適用版では151なのに旧版相当では9,999になっていました。
                旧版での問題の原因はリソースリークに確定ですね。

                • [161] Re7:速度測定 kobake 2008年03月01日 11:47

                  レビューを行いました。コミットして問題無いと思います。

                  多数の文字種を含むファイルを読み込んだときに、
                  旧版ではGDIオブジェクト数が増えてしまうのに対して、
                  パッチ適用版ではGDIオブジェクト数が増えないことを確認しました。

    • [93] Re:速度測定 kobake 2007年12月12日 23:29

      ▼ げんたさん
      > CRunningTimer使用時のコンパイルエラーを修正するパッチを出しました．
      > PatchUnicode#1842107

      遅くなりましたが、レビューを行いました。
      コミットして問題ないと思います。

      > TCHARで作り直した方がよいのでしょうかね．

      UNICODE系OSでchar文字列を吐き出すときに、多少の変換オーバーヘッドは生じると思います。
      でも個人的には、気にするレベルでは無いと思います。
      今のままで十分使えてるので、このままで良いかなぁ、と。