PR の目的

リファクタリングしてコードの可読性を上げるのが目的です。

カテゴリ

リファクタリング

PR の背景

データ要素のポインタ配列ではなく STL の std::vector コンテナを使うように変更しました。アウトライン解析データ要素の関数名とファイル名のメンバーの型を CNativeW から std::wstring に変更しました。

新しい実装の方がコードがすっきりして可読性が上がります。

PR のメリット

コードの可読性が上がります。

https://github.com/sakura-editor/sakura/pull/1644#issuecomment-826277859 でコメントした際には std::vector を使う事でメモリの動的確保の頻度を減らせると考えていましたが、アウトライン解析データ要素の関数名とファイル名のメンバーが文字列型でメモリを動的確保するので、あまり減らないかもしれません。

PR のデメリット (トレードオフとかあれば)

特にないと思います。

仕様・動作説明

リファクタリングなので処理内容には基本的に変更ありません。

PR の影響範囲

アウトライン解析処理

テスト内容

テスト1

手順

何かファイルを開く
アウトライン解析ウィンドウを表示する
リストの要素を選択してキャレットがその行に移動する事を確認
アウトライン解析ウィンドウを閉じて開きなおした時に現在のカーソル行の要素がリスト上で選択されている事を確認

関連 issue, PR

#1644

Apr 27 '21 20:04 beru

:white_check_mark: Build sakura 1.0.3712 completed (commit https://github.com/sakura-editor/sakura/commit/e6393eee00 by @beru)

Apr 27 '21 20:04 AppVeyorBot

:white_check_mark: Build sakura 1.0.3769 completed (commit https://github.com/sakura-editor/sakura/commit/1db1b47cad by @beru)

May 19 '21 01:05 AppVeyorBot

:white_check_mark: Build sakura 1.0.3770 completed (commit https://github.com/sakura-editor/sakura/commit/83ad28c113 by @beru)

May 19 '21 02:05 AppVeyorBot

:white_check_mark: Build sakura 1.0.3771 completed (commit https://github.com/sakura-editor/sakura/commit/d0053c2e41 by @beru)

May 19 '21 02:05 AppVeyorBot

:white_check_mark: Build sakura 1.0.3772 completed (commit https://github.com/sakura-editor/sakura/commit/67d4d6e64c by @beru)

May 19 '21 03:05 AppVeyorBot

:white_check_mark: Build sakura 1.0.3773 completed (commit https://github.com/sakura-editor/sakura/commit/c10602696c by @beru)

May 19 '21 04:05 AppVeyorBot

:white_check_mark: Build sakura 1.0.3774 completed (commit https://github.com/sakura-editor/sakura/commit/c4f5d1c0b3 by @beru)

May 19 '21 04:05 AppVeyorBot

:white_check_mark: Build sakura 1.0.3778 completed (commit https://github.com/sakura-editor/sakura/commit/5e8090a340 by @beru)

May 21 '21 01:05 AppVeyorBot

#1644 (comment) でコメントした際には std::vector を使う事でメモリの動的確保の頻度を減らせると考えていましたが、アウトライン解析データ要素の関数名とファイル名のメンバーが文字列型でメモリを動的確保するので、あまり減らないかもしれません。

CFuncInfoArr::AppendData を多数呼び出す CDocOutline::MakeTopicList_txt へ CRunningTimer を使った計測処理を入れ、反映前後での処理時間を比較してみました。ばらつきあるものの 10% 程度は速くなったようです。 (CDlgFuncList::SetData が圧倒的に時間がかかる (8秒程度) ので誤差のような処理時間ですけど……)

CDocOutline::MakeTopicList_txt の処理時間 (ms)：

	PR 反映前 (2e01db296 + 計測処理)	PR 反映後 (204010eea + 計測処理)
1回目	65.703	49.697
2回目	60.225	54.167
3回目	58.287	72.487
4回目	63.585	57.254
5回目	63.681	56.639

最大・最小を除いた平均	62.497	56.02

ビルド環境：Release/Win32 テストデータ：#1398 に添付されている test.zip の中の test_100k.txt 計測時の操作：test_100k.txt 読み込み後、アウトライン解析を表示し、F11 キーを 2 回押した時のログを取得

May 21 '21 05:05 suconbu

CFuncInfoArr::AppendData を多数呼び出す CDocOutline::MakeTopicList_txt へ CRunningTimer を使った計測処理を入れ、反映前後での処理時間を比較してみました。ばらつきあるものの 10% 程度は速くなったようです。 (CDlgFuncList::SetData が圧倒的に時間がかかる (8秒程度) ので誤差のような処理時間ですけど……)

そういえば処理時間の事を考えていませんでした。CDlgFuncList::SetData の処理時間は #1648 がマージされて高速化したので Rebase を行うようにします。

May 22 '21 05:05 beru

SonarCloud Quality Gate failed.

0 Bugs
0 Vulnerabilities
0 Security Hotspots
28 Code Smells