キャッシュが最適化されているため、（すべての要素を読み取る場合のように）ベクトルを反復処理する方が、リストを反復処理するよりも高速であると言われています。
パフォーマンスにどの程度の影響を与えるかを定量化するリソースはWeb上にありますか？
また、カスタムリンクリストを使用する方がよいでしょうか。どの要素がメモリ内で連続するように事前に割り当てられますか？
その背後にある考え方は、要素を変更されない特定の順序で格納したいということです。実行時にミッドルにすばやく挿入できるようにする必要がありますが、順序が変更されないため、ほとんどは連続しています。
要素が連続しているという事実は、キャッシュに影響を与えますか、それとも、list_element->next代わりに呼び出す++list_elementため、何も改善されませんか？
ベクトルとリストの主な違いは、ベクトルでは要素が事前に割り当てられたバッファ内で後で構築されるのに対し、リストでは要素が1つずつ構築されることです。結果として、ベクトル内の要素は連続したメモリスペースを占有するように許可されますが、リスト要素は（カスタムアロケータがそのように機能するなどの特定の状況を除いて）そのように許可されておらず、メモリー。
現在、プロセッサはメインメモリのページ全体を再マップするキャッシュ（メインRAMの最大1000倍の速度）で動作するため、要素が連続している場合は、同じメモリページに収まる可能性が高くなります。反復が開始されると、キャッシュ内ですべて一緒に移動されます。続行中、データをさらに移動したり、低速のRAMにアクセスしたりすることなく、すべてがキャッシュ内で実行されます。
list-sの場合、要素はどこでもまばらであるため、「次へ進む」とは、前のメモリページと同じメモリページにない可能性のあるアドレスを参照することを意味します。したがって、キャッシュは反復ステップごとに更新する必要があり、アクセスします。各反復でRAMが遅くなります。
std::allocatorパフォーマンスの違いは、プロセッサと、メインRAMとキャッシュの両方に使用されるメモリの種類、および（そして最終的にはとoperator new）の実装方法に大きく依存するmallocため、一般的な数値を指定することはできません。（注：大きな違いは、キャッシュに関してRAMが悪いことを意味しますが、リストの実装が悪いことも意味します）
データ構造のコンパクトな表現によるキャッシュコヒーレンシによる効率の向上は、かなり劇的なものになる可能性があります。リストと比較したベクトルの場合、コンパクトな表現は、読み取りだけでなく、Bjarneによるこの記事の図3に示されているように、特定のアーキテクチャで500K要素のオーダーまでの要素の挿入（ベクトルのシフト）にも適しています。 Stroustrup：
http://www2.research.att.com/~bs/Computer-Jan12.pdf
（発行元サイト： http： //www.computer.org/portal/web/csdl/doi/10.1109/MC.2011.353）
これがプログラムにとって重要な要素である場合は、アーキテクチャでプロファイルする必要があると思います。
私がそれを正しく説明できるかどうかはわかりませんが、ここに私の見解があります（私は以下の翻訳された機械命令の線に沿って考えています:)、
ベクトルイテレータ（連続メモリ）：ベクトルイテレータをインクリメントすると、イテレータ値は、次のオブジェクトを指すようにオブジェクトのサイズ（コンパイル時に既知）に追加されるだけです。ほとんどのCPUでは、これは最大で1〜3命令です。
リストイテレータ（リンクリストhttp://www.sgi.com/tech/stl/List.html）：リストイテレータ（ポイントされたオブジェクト）をインクリメントすると、転送リンクの場所は、番号を追加することによって特定されます。オブジェクトのベースがポイントされ、イテレータの新しい値としてロードされます。これには複数のメモリアクセスがあり、ベクトル反復操作よりも低速です。