回答:
オペレーションをセットアップするために必要なリソースです。それは無関係に見えるかもしれませんが、必要です。
どこかに行く必要があるとき、車が必要になるかもしれません。しかし、車で通りを走るのはかなりのオーバーヘッドになるので、歩いてみたいかもしれません。ただし、国中を移動する場合、オーバーヘッドは価値があります。
コンピュータサイエンスでは、より良い方法がないために車を使って通りを下る場合があります。または、「歩く方法を学ぶ」ことは時間の価値がありません。
単語の意味は、コンテキストによって大きく異なる場合があります。一般に、使用されるのはリソース（ほとんどの場合はメモリとCPU時間）であり、意図した結果には直接寄与しませんが、使用されているテクノロジまたは方法で必要とされます。例：
mallocは、ブロックのサイズとガード値で構成されるアロケーター（クラシック32ビットマシンを想定）のため、8バイトの組み込みオーバーヘッドがあります。そしてそれは、割り当ての細分性について考える前でもあります。したがって、単純な4バイト整数の単一リンクリストには、75％のオーバーヘッドがあります。配列はオーバーヘッドが1回（または配列が動的に割り当てられていない場合はそれ以下）になる可能性があるため、（途中で高速に挿入する必要がある場合を除いて）はるかに優れています。
ウィキペディアは私たちをカバーしています：
コンピュータサイエンスでは、オーバーヘッドは通常、特定の目標を達成するために必要な、過剰または間接的な計算時間、メモリ、帯域幅、またはその他のリソースの任意の組み合わせと見なされます。これはエンジニアリングオーバーヘッドの特殊なケースです。
オーバーヘッドは通常、さまざまなプログラミングアルゴリズムが使用する追加のリソース（メモリ、プロセッサ、時間など）の量に依存します。
たとえば、バランスの取れたバイナリツリーに挿入するオーバーヘッドは、単純なリンクリストへの同じ挿入よりもはるかに大きくなる可能性があります（挿入に時間がかかり、ツリーのバランスを取るためにより多くの処理能力を使用します。ユーザー）。
プログラマにとって、オーバーヘッドとは、特定の入力データセットの特定のプラットフォームで実行されているときに、コードによって消費されるシステムリソースを指します。通常、この用語は、異なる実装または可能な実装を比較する文脈で使用されます。
たとえば、特定のアプローチではかなりのCPUオーバーヘッドが発生する可能性があり、別のアプローチではより多くのメモリオーバーヘッドが発生し、さらに別のアプローチではネットワークオーバーヘッドに加重される可能性がある（たとえば、外部依存関係を伴う）と言えます。
具体的な例を挙げましょう：一連の数値の平均（算術平均）を計算します。
明白なアプローチは、実行合計とカウントを維持しながら入力をループすることです。最後の数値が検出されると（「ファイルの終わり」のEOF、または何らかのセンチネル値、またはGUIボタンなどによって通知されます）、合計を入力数で除算するだけで完了です。
このアプローチでは、CPU、メモリ、またはその他のリソースに関するオーバーヘッドはほとんど発生しません。（それは簡単な仕事です）。
別の可能なアプローチは、入力をリストに「丸める」ことです。リストを反復処理して合計を計算し、それをリストからの有効な項目の数で割ります。
比較すると、このアプローチでは任意の量のメモリオーバーヘッドが発生する可能性があります。
特定の不適切な実装では、再帰を使用して合計操作を実行する場合がありますが、末尾削除はありません。ここで、リストのメモリオーバーヘッドに加えて、スタックオーバーヘッドも導入します（これは、メモリの種類が異なり、多くの場合、他の形式のメモリよりもリソースが制限されます）。
さらに別の（おそらくもっとばかげた）アプローチは、RDBMSのSQLテーブルにすべての入力をポストすることです。次に、そのテーブルのその列でSQL SUM関数を呼び出すだけです。これにより、ローカルメモリのオーバーヘッドが他のサーバーにシフトし、ネットワークオーバーヘッドと外部依存関係が発生します。（リモートサーバーには、このタスクに関連する特定のメモリオーバーヘッドがある場合とない場合があることに注意してください。たとえば、すべての値がストレージにすぐに排出される場合があります）。
仮説として、ある種のクラスターに対する実装を検討する場合があります（おそらく数兆個の値の平均化を実現可能にするため）。この場合、必要な値のエンコードと値の分散（それらをノードにマッピング）、および結果の収集/照合（縮小）はオーバーヘッドとしてカウントされます。
プログラマー自身のコード以外の要因によって発生するオーバーヘッドについても説明できます。たとえば、32ビットまたは64ビットプロセッサのコードをコンパイルすると、古い8ビットまたは16ビットアーキテクチャの場合よりもオーバーヘッドが大きくなる可能性があります。これには、より大きなメモリオーバーヘッド（アライメントの問題）またはCPUオーバーヘッド（CPUがビットの順序を調整するように強制される、またはアライメントされていない命令を使用するなど）またはその両方が含まれる場合があります。
コードやライブラリなどが占めるディスク容量は、通常「オーバーヘッド」と呼ばれるのではなく、「フットプリント」と呼ばれます。また、プログラムが消費するベースメモリは（処理するデータセットに関係なく）、「フットプリント」とも呼ばれます。
オーバーヘッドとは、単にプログラムの実行にかかる時間のことです。例; 関数を呼び出し、そのコントロールが定義された場所に渡され、その本体が実行されると、CPUが長いプロセスを実行するようになります（最初にコントロールをメモリ内の他の場所に渡してから、そこで実行します。コントロールを元の位置に戻す）、その結果、多くのパフォーマンス時間がかかるため、オーバーヘッドが発生します。私たちの目標は、関数の定義と呼び出し時にインラインを使用することでこのオーバーヘッドを削減することです。これにより、関数呼び出しで関数のコンテンツがコピーされるため、コントロールを他の場所に渡さず、プログラムを1行に続けるため、インラインで。
オーバーヘッドの具体例は、「ローカル」プロシージャコールと「リモート」プロシージャコールの違いです。
たとえば、従来のRPC（およびEJBのような他の多くのリモートフレームワーク）では、関数またはメソッドの呼び出しは、ローカルのメモリ内呼び出しでも、分散ネットワーク呼び出しでも、コーダーにとって同じように見えます。
例えば：
service.function(param1, param2);
それは通常の方法ですか、それともリモートの方法ですか？ここで目にするものからはわかりません。
しかし、2つの呼び出しの実行時間の違いが劇的であると想像できます。
そのため、コア実装は「同じコスト」になりますが、関連する「オーバーヘッド」はかなり異なります。