これはメモリのオーバーヘッドではありませんか？
そうですね？
マシンのメモリアドレス範囲と、スタックに結び付けられない方法でメモリ内の場所を継続的に追跡する必要があるソフトウェアを想像してください。これは厄介な問題です。
たとえば、ユーザーがボタンを押すだけで音楽ファイルがロードされ、ユーザーが別の音楽ファイルをロードしようとすると揮発性メモリからアンロードされる音楽プレーヤーを想像してください。
オーディオデータが保存されている場所をどのように追跡しますか？メモリアドレスが必要です。プログラムは、メモリ内のオーディオデータチャンクだけでなく、メモリ内の場所も追跡する必要があります。したがって、メモリアドレス（つまり、ポインタ）を保持する必要があります。また、メモリアドレスに必要なストレージのサイズは、マシンのアドレス範囲と一致します（例：64ビットアドレス範囲の場合は64ビットポインター）。
したがって、それは一種の「はい」であり、メモリアドレスを追跡するためにストレージが必要ですが、この種の動的に割り当てられたメモリに対してそれを回避できるわけではありません。
これはどのように補償されますか？
ポインター自体のサイズについて言えば、スタックを利用することにより、場合によってはコストを回避できます。その場合、コンパイラーは、ポインターのコストを回避して、相対メモリアドレスを効果的にハードコードする命令を生成できます。しかし、これにより、大規模な可変サイズの割り当てに対してこれを行うとスタックオーバーフローに対して脆弱になり、ユーザー入力によって駆動される複雑な一連のブランチ（オーディオの例のように）上記）。
別の方法は、より連続したデータ構造を使用することです。たとえば、ノードごとに2つのポインターを必要とする二重リンクリストの代わりに、配列ベースのシーケンスを使用できます。また、これら2つの要素のハイブリッドを使用して、N個の要素のすべての連続したグループの間にポインターのみを格納する展開されたリストのようにすることもできます。
ポインターは、タイムクリティカルな低メモリアプリケーションで使用されていますか？
多くのパフォーマンス・クリティカルなアプリケーションは、ポインタの使用状況によって支配されているCまたはC ++で書かれているようはい、非常に一般的にそう、（彼らはスマートポインタなどの容器の後ろかもしれませんstd::vectorかstd::string、しかし、根本的な仕組みは使用されているポインタに煮詰めます動的メモリブロックへのアドレスを追跡するため）。
この質問に戻りましょう：
これはどのように補償されますか？（パート2）
ポインターは通常、100万個（64ビットマシンではまだわずか8メガバイト）を格納している場合を除き、非常に安価です。
* Benが指摘したように、「わずかな」8メガバイトは依然としてL3キャッシュのサイズであることに注意してください。ここでは、DRAMの総使用量と、ポインターの健全な使用が指すメモリチャンクに対する一般的な相対サイズという意味で、「わずか」に使用しました。
ポインターが高価になるのは、ポインター自体ではなく、次のとおりです。
動的メモリ割り当て。動的メモリ割り当ては、基礎となるデータ構造（バディまたはスラブアロケーターなど）を経由する必要があるため、高価になる傾向があります。これらは多くの場合死に最適化されていますが、汎用であり、「検索」に似た少なくとも少しの作業を行う必要がある可変サイズのブロックを処理するように設計されています。メモリ内の連続したページの空きセットを見つけます。
メモリアクセス。これは、心配する大きなオーバーヘッドになる傾向があります。動的に割り当てられたメモリに初めてアクセスするたびに、強制的なページフォールトとキャッシュミスが発生し、メモリがメモリ階層を下ってレジスタに移動します。
メモリアクセス
メモリアクセスは、アルゴリズムを超えるパフォーマンスの最も重要な側面の1つです。AAAゲームエンジンのようなパフォーマンスが重要なフィールドの多くは、より効率的なメモリアクセスパターンとレイアウトに要約されるデータ指向の最適化に多大なエネルギーを集中しています。
ガベージコレクターを介して各ユーザー定義型を個別に割り当てたい高レベル言語の最大のパフォーマンスの難しさの1つは、たとえば、かなりの量のメモリをフラグメント化できることです。これは、すべてのオブジェクトが一度に割り当てられるわけではない場合に特に当てはまります。
そのような場合、ユーザー定義オブジェクトタイプの100万個のインスタンスのリストを保存すると、異なるメモリ領域を指す100万個のポインターのリストに類似しているため、ループでそれらのインスタンスに順番にアクセスするのは非常に遅くなる可能性があります。そのような場合、アーキテクチャは、追い出される前にそれらのチャンク内の周辺データにアクセスできることを期待して、大きく整列したチャンクの上位、低速、大規模な階層からメモリをフェッチします。そのようなリスト内の各オブジェクトが個別に割り当てられると、エビクション前にアクセスされる隣接オブジェクトがない状態で、後続の各反復がメモリ内の完全に異なる領域からロードしなければならない場合に、キャッシュミスで支払うことになります。
このような言語のコンパイラの多くは、最近、命令の選択とレジスタの割り当てで本当に素晴らしい仕事をしていますが、ここでのメモリ管理をより直接制御できないと、（多くの場合エラーが少なくなりますが）致命的であり、 CとC ++は非常に人気があります。
ポインターアクセスの間接的な最適化
最もパフォーマンスが重要なシナリオでは、アプリケーションは多くの場合、参照の局所性を向上させるために連続するチャンクからメモリをプールするメモリプールを使用します。そのような場合、そのノードのメモリレイアウトが本質的に連続していれば、ツリーやリンクリストのようなリンクされた構造でさえ、キャッシュフレンドリーにすることができます。これにより、間接的に参照を行うときに関連する参照の局所性を改善することで、間接的にではなく、ポインターの逆参照を効果的に行うことができます。
ポインタを追いかける
次のような単一リンクのリストがあると仮定します。
Foo->Bar->Baz->null
問題は、これらのすべてのノードを汎用アロケーターに対して個別に割り当てると（そして、一度にすべてではない可能性がある）、実際のメモリが次のように多少分散する可能性があることです（簡略図）。
ポインターを追いかけてFooノードにアクセスすると、強制的なミス（およびおそらくページフォールト）から始まり、次のように、メモリ領域から低速のメモリ領域から高速のメモリ領域にチャンクを移動します。
これにより、メモリ領域をキャッシュ（おそらくページ）し、その一部にのみアクセスし、このリストの周りのポインタを追いかけながら残りを排除します。ただし、メモリアロケーターを制御することにより、次のようにこのようなリストを連続して割り当てることができます。
...これにより、これらのポインタを逆参照し、ポインティを処理できる速度が大幅に向上します。したがって、非常に間接的ではありますが、この方法でポインターアクセスを高速化できます。もちろん、これらを配列に連続して格納しただけであれば、そもそもこの問題は発生しませんが、ここでメモリレイアウトを明示的に制御できるメモリアロケータは、リンクされた構造が必要になる日を節約できます。
*注：これは、参照のメモリ階層とローカリティに関する非常に単純化された図と説明ですが、問題のレベルに適していることを願っています。