毎秒10以上のアイテムをトレネルリストに追加するアプリケーションがあります。これにより、コントロールとUIが反応しなくなり、十分にペイントできなくなることもあり、多くのCPUを消費します。コントロールペイントスパムの回避（treeview、listviewコントロールの更新中）
これらの新しい項目は異なるスレッドから来ているので、私はローカルキャッシュの何らかの並べ替えをしない限り.BeginUpdate()を使用できません。
BeginUpdate（）とEndUpdateを一定の間隔で実行すると、間隔の間に塗装されていない/空白が残っていることを制御できます。
この問題に対する最良の解決策は何ですか？理論的にはコントロールが自分のキャッシングを持っているので、キャッシングは私にとっては馬鹿だと思うので、コントロールを更新しないようにする方法があるはずですが、
新しい項目は、すでにControl.Invokeが必要な別のスレッドから来ているので、それをバッチすることもできます。したがって、アイテムをキューにプッシュし、メインスレッドでそのキューをポーリングして（おそらくタイマーを使用して）、BeginUpdate/EndUpdateブロックにアイテムのバッチを追加します。タイマー間隔で応答性を設定できます。キューをロックする必要がありますが、Invokeは必要ありません。
追加をサポートしているスレッドが複数ある場合は、コントロールの所有スレッドにマーシャリングする必要があります。
このように、マーシャリング後の単一のバッチ処理メカニズムを実装するのは簡単です。
コントロールのキャッシングは、特定の要件を考慮して設計されているとは限りません（この種のウィジェットツールキットでは通常の動作ではありません）。したがって、ロードと応答性のニーズに特有のキャッシュを使用すると効果的です。
あなたの問題は他のものよりもアプリケーションの応答性であるように見えます。 10個のアイテムは非常に重くはない（非常に重いアイテムでない限り）ので、問題を引き起こしません。
Application.DoEventsを追加すると、期待どおりにアプリケーションが応答すると思います。問題は、実行されている負荷ではなく、タイムリーなフェージングでWindowsメッセージを処理することにあるようです。
コントロールにアイテムを追加するには、メインスレッドを呼び出す必要があります。したがって、DoEventsを数秒で1回呼び出すことに問題はありません。これは大いに効率的な解決策ではありませんが、あなたの責任の不足に対処すると思います。
私はdoeventsではないinvokeを使用しています。 –
はい、問題の理解は、アプリケーションが応答しないということでした。私の推測では、問題は負荷ではなくメッセージを処理する能力であるということです。 DoEventsを追加すると、呼び出しを使用するかどうかにかかわらず、アプリケーションが応答性が高くなる可能性があります。 奇妙に思えるのは、わずか10秒間は応答のないアプリなので、CPU負荷ではなく処理時間だと思っています。 – Tollo