私はプログラミングの世界に比較的慣れていません。パフォーマンスに関する質問がいくつかあります。
コンソール アプリは、グラフィカル ユーザー インターフェイスを備えたアプリよりも高速に実行されますか?
C や Pascal などの言語は、C++ や Delphi などのオブジェクト指向言語よりも高速ですか? 言語の速度は、言語自体よりもコンパイラに大きく依存することは知っていますが、手続き型言語のコンパイラは、オブジェクト指向言語 (C コードを生成できる C++ コンパイラを含む) よりも高速なコードを生成しますか?
コンソール アプリは Windows ベースのアプリよりも高速に実行されますか
短い答え:いいえ
長い答え:
コンソール ベースのアプリケーションでは、ウィンドウを再描画してユーザー入力を受け入れる必要がある GUI スレッドがないため、その意味では、コンソール アプリケーションの方がわずかに高速である可能性があります (CPU サイクルを盗むスレッドが 1 つ少ないため)。ただし、最近のオペレーティング システムは複数のプロセスを同時に実行するため、いずれにせよ、コンソール アプリケーションはシステム内の他のプロセスと CPU をめぐって競合します。
c や pascal などの言語は、c++ や delphi などのオブジェクト指向言語よりも高速ですか?
短い答え:いいえ
長い答え:
C と C++ の同等のプログラムは、ほぼ同じように動作します。プログラミング言語は確かにパフォーマンスに影響を与える可能性がありますが、一般的に主に考慮する必要があるのはアルゴリズム (アプリケーションのロジックで何を表現するか) であり、アルゴリズムがコード化されている言語ではありません。
Michael Aaron Safyan はすでに非常に良い答えを出しています。オブジェクト指向言語が遅いコードに関連付けられることがある理由について、少しだけ貢献したいと思います。
私たちプログラマーに対する現実世界の要求は、より短い時間でより多くのコードを書くことを私たちに強い続けています。非常に熟練したプログラマーがいるとすれば、プログラマーはマシンが実行する必要のある操作を正確にコーディングし、それ以外はほとんどないため、アセンブリ言語はすべての速度記録を獲得します。実際には、面倒でエラーが発生しやすいため、ほとんどのプログラミングはアセンブラーで行われません。コンパイルされた言語を使用すると、コンパイラーが詳細な作業の多くを処理できるため、プログラマーの生産性が大幅に向上します。
さらに同じ方向に進むと、Delphi は自動文字列で動作します。これらは、使用されるたびに「適切な」長さになります。2 つの文字列を連結すると、前の文字列の組み合わせに適した長さの新しい文字列が生成されます。その文字列を変更して長くすると、新しい文字列が作成され、以前の文字列は自動的に破棄されます。C プログラマーとして、プログラムが何をするかを予測し、より大きな文字列に十分なスペースを割り当てることができたので、新しい文字列を作成して古い文字列を破棄する必要はありませんでした。したがって、文字列のメモリ管理は、CPU 時間をいくらか犠牲にして購入したプログラマーにとって便利です。
同様に、オブジェクト指向では、関連するデータのグループを、文字列や数値ではなく同種のチャンクとして扱うことができます。場合によっては、この情報のすべてが必要なわけではなく、低レベルの C プログラムでは、オブジェクトが発生する操作やメモリ使用の一部を省略できる場合があります。これもまた、CPU 速度よりもプログラマーの利便性の問題です。
最後に、一部のインターフェースは非常に複雑であると考えられており、ソフトウェア会社は、概念的により単純な処理を備えたオブジェクト指向フレームワークを作成することによって、それらを親しみやすいものにしようとしています。ウィンドウを開く呼び出しを行うのではなく、ウィンドウ オブジェクトを作成することができますが、通常は少しオーバーヘッドがかかります。奇妙な開発では、ソフトウェア会社や個々の開発者が、他のフレームワークの複雑さを隠したり処理したりするために、さらにオブジェクト指向のフレームワークを構築することがよくあります。一部の古いプロジェクトでは、元の機能の上にオブジェクト指向フレームワークの複数のレイヤーが追加されてしまいます。当然のことながら、プロジェクト自体の管理に多くの時間を費やしているため、多くのメモリを消費しながら、パフォーマンスが低下していることを顧客に示しています。
要約すると、オブジェクト指向コードは、その使用方法によってパフォーマンスが低下することがあります。しかし、特に C++ の場合、言語自体が「遅い」ということはありません。
既に述べたように、コードは通常、コンソール アプリケーションでも GUI アプリケーションと同じように高速に実行されます。
本当の違いはオーバーヘッドです。すべてが同じであれば、GUI アプリケーションはより大きな EXE であり、起動と終了に少し時間がかかり、より多くのリソースを消費します。また、アプリの実行中に UI を更新するのも良い方法です。これにより、CPU を集中的に使用するタスクからサイクルが奪われる可能性があります。
しかし、ほとんどの場合は問題になりません。
メッセージ マップ、ウィンドウ イベント、GUI スレッドなどがないため、コンソール アプリは、ウィンドウ ベースのアプリよりも高速なパフォーマンスを持っているように見えるかもしれません。ただし、コンソール アプリとウィンドウ ベースのアプリのどちらを選択するかは、速度だけを基準にするべきではありません。ご存じかもしれませんが、Windows アプリは「イベント駆動型プログラミング」です。
言語速度に関しては、C コンパイラだけがより高速な実行コードを生成するとは言えません。実際、c++ コンパイラは、コンパイルされたコードの速度を最大化するために多くのコード最適化を行います。また、オブジェクト指向モデルは、機能を簡単にプログラム、保守、および拡張するのに非常に適しています。
そのため、要件に基づいて適切な言語と技術を使用してください
同じコンパイラによって生成された同じコードは、GUI アプリまたはコンソールで実行されているかどうかに関係なく、同じ速度で実行されます。さらに、C++ としてコンパイルされた C コード (C++ 準拠でもあることを考えると) は、C としてコンパイルされた同じコードとまったく異なる場合でも、大きな違いはありません。
ただし、パフォーマンスに影響を与える可能性のある OS の側面があります。OS または I/O 呼び出しでブロックされない限り、コンソール アプリはタイム スライス全体を消費します。通常、GUI アプリはイベント駆動型であるため、イベントが処理されるのを待ってから、次のイベントを待ちます。ただし、コンソール アプリと同様に動作するワーカー スレッドがある場合があります。また、GUI アプリは必然的に、より複雑な表示の更新に時間を費やすことになります。ただし、これらの側面は、コンパイラではなく、アプリケーション設計者と OS の管理下にあります。
OOP に関しては、本質的に遅いというわけではありませんが、より迅速なアプリケーション開発と優れた保守性と堅牢性につながるコンストラクトとアーキテクチャがありますが、パフォーマンスとのトレードオフを伴う可能性があります。
c や pascal などの言語は、c++ や delphi などのオブジェクト指向言語よりも高速ですか?
いいえ、逆の場合もあります。
Dav がコメントで述べたように、コードはアプリケーションの速度を決定します。これは、コンパイラの反対側である生成されたマシン コードにも当てはまります。
一般に、新しいコンパイラは、高度な CPU 機能を利用し、以前のコンパイラには見られなかった最新のコンパイラ最適化を実行するため、より高速なマシン コードを生成することがよくあります。
たとえば、古い Turbo Pascal コンパイラではなく、Delphi でコンパイルした方が高速に実行される Pascal アプリケーションを作成することは十分に可能です。
一言で言えば、より軽量に見えるという理由だけで、古い/プリミティブなコンパイラを使用しないでください。ほとんどの場合、パフォーマンスは向上しません。
これは最初の質問にのみ適用されます。
コンソール アプリがグラフィカル環境 (GNOME デスクトップや Windows など) で対話的に実行される場合、実際には GUI アプリであるターミナル ウィンドウ内で実行されます。そのため、GUI のコスト (メッセージ ループを実行する必要がある、GUI ウィジェットを割り当てる必要がないなど) は、ホスティング環境に単純に転送されます。コンソール アプリをフル スクリーン (テキスト モードスクリーン) で実行すると、CPU とビデオ カード間のトラフィックが減少しますが、速度の向上は無視できます。
ただし、コンソール UI は、グラフィック出力の柔軟性が低いという代償を払って、はるかに簡単に開発できます。ncurses でフォームを作成するのにかかる労力と、GTK を使用して必要な労力を比較してください。
この問題で私を助けてくれた人々に感謝しますが、私はまだ混乱しています.oo言語についての私の衝動は、ライブラリが肥大化しているため、パフォーマンスのオーバーヘッドがあるということです。 c++で利用可能な通常のライブラリはc++をcより遅くします。プログラムをコンパイルするためにdelphi 2010の代わりにdelphi7を使用すると、パスカルとデルファイにも同じことが当てはまります。デルファイ2010ユニットは重いため、より高速に実行されます（警告：デルファイ7と2010を比較したことはありませんC++ と C を比較したことがありますか? オンライン フォーラムや言語対言語の討論を読んで作成した私の印象です) あなたは私が頭がおかしいと思うかもしれませんが、私は完璧に動作するプログラム (テキスト エディターと同じくらいマイナーなものであっても) を好むでしょう私のプログラムがスーパーコンピューターで実行されたとしても、コードを最適化したいのですが、強迫性パーソナリティ障害があるかもしれません:)
2 番目の質問については、Michael と Carl に同意し、別の考慮事項を追加したいと思います。つまり、自然は真空を嫌うということです。これはソース コードにも当てはまります。
高水準言語では、より少ないコードで同じ作業を行うことができるため、たとえそれが必要でなくても、同じコードでより多くの作業を行うことができます。
したがって、たとえば、次のようなSOの質問が表示されることがあります。
time starttime = now;
for (i = 0; i < 1000000; i++){
cout << i;
}
cout << (now - starttime);
そして、これがループ オーバーヘッドの倍になるかどうかを尋ねます。暗黙のうちに、<<2 文字しかないため無視できると仮定します。実際、ループの<<内側では、ループよりも数千倍のサイクルが必要です。私の経験では、これは私を含むほぼすべてのプログラマーによってさまざまな方法で行われています。彼らは、非常に少ないコードで多くのことができることに感謝し、多くのことを行い、自分がやった場合はそうだったと思い込んでいます。必要です。
そのため、言語のレベルが高いほど、パフォーマンス チューニングのスキルが重要になります。