ほとんどのアルゴリズムでは、スタックでのデータの割り当てと割り当て解除は、ヒープで行うよりもはるかに高速であることが広く知られています。C ++では、コードの違いは次のようになります。
double foo[n*n]
対。
double* foo = new int[n*n]
しかし、ヒープまたはスタックのいずれかにあるデータにアクセスして計算する場合、大きな違いはありますか？つまり、速度差があります
foo[i]
コードはいくつかの異なるアーキテクチャで実行する必要があるため、試行と測定は機能しません。
キャッシュの局所性と読み取り/書き込みミスに関して（システムに大きく依存する）問題がある可能性があります。プログラムをスタックとヒープデータで実行する場合、スタックの1つの連続領域で完全に実行する場合よりも、（キャッシュアーキテクチャに応じて）より多くのキャッシュミスが発生する可能性があります。Andrew Appel（SML / NJから）とZhong Shaoによるこの問題の論文は、スタック/ヒープの割り当てが関数型言語の実装のトピックであるため、まさにこのことを調査しています。
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.3778
彼らは書き込みミスに関するいくつかのパフォーマンスの問題を発見しましたが、これらはキャッシングの進歩によって解決されると推定しました。
したがって、現代のデスクトップ/サーバーマシンについての私の推測では、キャッシュラインに沿ってデータをストリーミングする高度に最適化されたアーキテクチャ固有のコードを実行していない限り、スタックアクセスとヒープアクセスの違いに気付くことはありません。キャッシュが小さいデバイス（ARM / MIPSコントローラーなど）では状況が異なる場合があり、キャッシュを無視すると、とにかくパフォーマンスに顕著な影響を与える可能性があります。
スタックはより頻繁にCPUキャッシュにあるため、場合によってはより高速になる可能性があります。
しかし、最も正確な答えはおそらく：それは依存します...
単一のステートメントとしてとらえれば、それは問題ではありません。
これ以上の文脈がなければ、ほとんど何も言えません。スタックを支持するいくつかの影響がありますが、これらは事実上常に無視できます。
スタックはすでにキャッシュにある可能性がありますが、新しく割り当てられたヒープブロックはそうではない可能性があります。ただし、これは最初の実行ペナルティのみです。大量のデータについては、とにかくキャッシュを破棄します
スタック割り当て自体は、割り当てが単純であるため、ヒープ割り当てよりも少し安価です。
長期的には、ヒープの主な問題は通常、断片化です。これは「累積コスト」であり、（通常は）単一の割り当てに起因するものではありませんが、それ以上の割り当てのコストが大幅に増加する可能性があります。
これらの効果を測定することは、少なくとも注意が必要です。
推奨事項：ここでは、パフォーマンスが決定要因ではありません。移植性とスケーラビリティは、ごく少量のデータを除くすべてのデータにヒープを使用することをお勧めします。
割り当てを除けば、データへのアクセスにスタックベースかヒープベースかに関係なく、識別可能な違いはないはずです。データは1日の終わりにすべてメモリになります。