2009-09-02 3 views
0

.NETでFileInfoオブジェクトのコレクションをソートしようとしました。私たちはIComparerを実装し、FileInfoオブジェクトが私たちの基準に基づいてソートされていることを確認しました。その後、FileInfoオブジェクトのソートのパフォーマンスは、単なるintよりも何倍も遅かったことに気付きました。 (そしてC言語での参照の仕組みを思い出して)、ローカル変数を使ってFileInfoプロパティを参照する回数を制限することで、パフォーマンスを向上させることができました。Sorting Reference TypeとValue Typeのパフォーマンス

私の考えは、オブジェクトのプロパティよりローカル変数がアクセスする方が速いということでした。私は、管理されていないコードの世界では、スタックがどのように動作し、値がどのように参照されるかを実際に示すことができます。しかし、私はマネージコードの世界がカバーの下でもっと複雑になる可能性があることを知っています。私の質問は次のとおりです。管理されていないコードのメモリ管理とプログラムフローの基本的な考え方は、一般的にマネージコードの世界に投影されますか?

最終的にKeeperOfTheSoulの助けを借りて、これをFileInfoオブジェクトをどうやって模倣したかを追跡することができました。そのため、RhinoMockタグをこのクエスチョンに追加しました。

答えて

1

比較メソッドの実装を除いて、参照型と比較して値の型をソートする間に、実際には速度の違いはありません。私がsinを使った比較メソッドを実装した場合、intもゆっくりとソートされます。

プロパティへのアクセスには、ローカル変数にアクセスしている間にメソッド呼び出しが関与しますが、その値は直接スタック上にあるか、レジスタに既に存在しています。しかし、単純なプロパティは、JITによってインライン化に似たものを提供するように最適化することができます。

この場合、FileInfoはプロパティ値を取得するためにファイルシステムの読み込みを必要とする可能性があり、FileInfoが内部的に値をキャッシュしないと、この読み込みを繰り返し実行する可能性があります。

+0

FileInfoオブジェクトがファイルシステムに直接アクセスしているとは思いません。私たちのテストでは、実際にRhinoMockを使ってFileInfoオブジェクトを嘲笑していました。これは良い点をもたらしました。私たちのテストを遅くしていたRhinoMockフレームワークでしたか? – LJM

+0

おそらく、私はrhinoモックが、JITの最適化が効率的になるのを阻止するのに十分なことはありますか? –

+0

私は検証するためにいくつかのテストを実行しましたが、それは確かに疑わしいオブジェクトのパフォーマンスのように見えます。助けてくれてありがとう。 – LJM

関連する問題