0

プログラムでいくつかのパフォーマンスの問題を観察した後、プロファイリング セッションを実行することにしました。結果は、採取されたサンプルの 87% 程度が何らかの形で私のUpdate()機能に関連していることを示しているようです。

この関数では、 72 に等しい のリストを調べ、処理後にそれらを削除しますA*。sizeof(A)

void Update()
{
//...

    for(auto i = myList.begin(); i != myList.end(); i++)
    {
        A* pA = *i;
        //Process item before deleting it.
        delete pA;
    }

     myList.clear();

//...
}

myList はstd::list<A*>です。平均して、リストに平均 5 つの項目が含まれている間、この関数を 1 秒あたり 30 ～ 60 回呼び出しています。つまり、A1 秒あたり 150 から 300 個のオブジェクトを削除しているということです。

ほとんどの場合、delete を何度も呼び出すだけでパフォーマンスの問題が発生するでしょうか? 関数内で問題が発生している場所を正確に追跡する方法はありますか? 削除は一般的に高価な操作と見なされますか?

4

3 に答える 3

1

おそらくループで行われる作業の大部分をブラッシングし、 A が何であるかについてのヒントを与えないため、見分けるのは非常に困難です...

A がデータ、特にプリミティブの単純なコレクションである場合、削除が原因ではないことはほぼ確実です。update 関数を update と uninit の 2 つに分割することで、この理論をテストできます。Update はすべての処理を行い、uninit はオブジェクトを削除してリストをクリアします。

更新だけが遅い場合、それは処理です。uninit だけが遅い場合、それは削除です。どちらも遅い場合は、メモリの断片化が原因である可能性があります。

コメントで他の人が指摘しているように、 std::vector を使用するとパフォーマンスが向上する場合があります。ただし、データ構造の構築方法によっては、他の場所でもパフォーマンスの問題が発生する可能性があるため、注意してください。

于 2012-12-13T21:00:16.457 に答える
0

何が起こっているのかを簡単に知ることができます。

自分に有利に働き、この方法を使用してください。n度まで分析されており、非常に効果的です。

一言で言えば、87％の時間が入ってUpdateいる場合、Ctrl-Cなどで数回停止すると、その行為でキャッチするたびに87％の確率になります。

にあることがわかるだけではありませんUpdate。のどこにUpdate、何をしているのかがわかります。の処理中delete、またはデータ構造へのアクセス中の場合は、それが表示されます。また、スタックのさらに下に、その操作に時間がかかる理由が表示されます。

于 2012-12-13T23:08:47.620 に答える
0

gperftools (Google Performance Tools)のtcmallocを参照してください。gperftools にはプロファイラも含まれています (両方のライブラリをリンクするだけで、非常に簡単です)。tcmalloc は小さなオブジェクト用のメモリ プールを保持し、可能な場合はこのメモリを再利用します。プロファイラーは、CPU とヒープのプロファイリングに使用できます。

于 2012-12-13T22:57:46.510 に答える