私はunique_ptrの巨大なベクトルを持っています。呼び出しのベクトルデストラクタまたは別のスレッドでクリア
clear（）を実行するか、デストラクタを呼び出す必要があるときには4-5秒かかりました。
スピードアップする一つの理論的方法は、私が働いている巨大なベクトルとそれをスワップし、次にスレッドを開始し、tempベクトルをクリアすることです。
私はこのような最適化のために話す人はいません。
私の最適化に欠陥がありますか？
あなたのアイデアはうまくいくはずです。たとえば、あなたがXと呼ばれるいくつかのデータのstd::vectorを持っている場合：
DataStorage data;
// data usage
auto clear_task = std::async(std::launch::async,
&DataStorage::clear, std::move(data));
// do some stuff here; data object is not used anymore
clear_task.wait();
を不要なコピーはここにありません：
struct X
{
// some data here
};
using DataStorage = std::vector<std::unique_ptr<X>>;
あなたはDataStorageオブジェクトを移動し、非同期的に、このオブジェクトにclear()を呼び出すためにstd::asyncを使用する場合があります：dataに移動し、別のスレッドでclear()を呼び出すように指定すると、クリアな操作が実行されている間にメインスレッドがハングしません。
はい、スワップ/移動のポイントは、すぐに空のベクトルを使用することができます。 – Nick
@ニック移動後に 'std :: vector'を使うことはできないと思います。しかし、あなたが言及したようにスワップを行い、空のベクトルを扱うかもしれません。 –
可能性があります。異なる割り当てスキームを思いついて、割り当ての数が少なくて済むかもしれません。 –
誰もそれについて話していない理由は次のとおりです。あなたは非常に特殊なリクエスト+ちょっとあります直感的で些細なこと（鈍いことには申し訳ありません）。 –
fyi：ヒープは共有リソースであり、割り当て/削除時にロックする必要があります。したがって、バックグラウンドスレッドは、ベクターの削除が完了するまで、ヒープを「所有」します。あなたのメインスレッド（std :: string、std :: vectorなど）の割り当ては、ヒープロックのために競合する必要があります。 –