前の記事の続きで、CWorkspaceと言うツリー型データ管理クラスの話です。
前の記事でXMLへの出力を高速化した所、データのコピーより、一旦XMLに変換して再ロードしたほうが10倍以上早いと言う謎の状態になりました(笑
データコピーは、ツリーを再帰的にコピーして行くよう実装されており、特段遅くなる理由も見つかりません。
よくよく調べてみると、XMLの時と同じくCString原因のようです。
再帰的にコピーする時、再起呼出しごとに新たにCStringを確保しているのが問題のようでした。
CStringは、MFCとATLで使用できる文字列クラスですが、こいつの確保に時間を食っているようです。
ちゃんとコードを読んでみないと分かりませんが、CStringは毎回newでメモリを確保しているわけではなさそうです。
高速化のためにメモリプールを使ってるのでしょうか?
それでも速度の低下が発生してしまうので、私の使い方は、CStringの設計者の想定外のようです。
CStringを使用しないようコードを書き直したところ、十分なパフォーマンスが出るようになりました。
CStringの確保は、毎回new等でメモリを確保するよりも高速なようですが、あまりに大量に確保するような使い方はよした方がよさそうです。
※追記
CStringのメモリマネージャは自分で実装することもできるようです。
また、CStringがコピーされる場合、変更が加えられるまで前の文字列と同じメモリ領域を共有し、確保とコピーはされないようです。
前の記事でXMLへの出力を高速化した所、データのコピーより、一旦XMLに変換して再ロードしたほうが10倍以上早いと言う謎の状態になりました(笑
データコピーは、ツリーを再帰的にコピーして行くよう実装されており、特段遅くなる理由も見つかりません。
よくよく調べてみると、XMLの時と同じくCString原因のようです。
再帰的にコピーする時、再起呼出しごとに新たにCStringを確保しているのが問題のようでした。
CStringは、MFCとATLで使用できる文字列クラスですが、こいつの確保に時間を食っているようです。
ちゃんとコードを読んでみないと分かりませんが、CStringは毎回newでメモリを確保しているわけではなさそうです。
高速化のためにメモリプールを使ってるのでしょうか?
それでも速度の低下が発生してしまうので、私の使い方は、CStringの設計者の想定外のようです。
CStringを使用しないようコードを書き直したところ、十分なパフォーマンスが出るようになりました。
CStringの確保は、毎回new等でメモリを確保するよりも高速なようですが、あまりに大量に確保するような使い方はよした方がよさそうです。
※追記
CStringのメモリマネージャは自分で実装することもできるようです。
また、CStringがコピーされる場合、変更が加えられるまで前の文字列と同じメモリ領域を共有し、確保とコピーはされないようです。