プログラミング言語のパフォーマンスの低下は本当に悪いことですか？
これが私の見方です。
machine code があり、コンピュータが何かを実行するために必要なのはそれだけです。コンピュータはプログラミング言語を気にしません。マシンコードがPerl、PythonまたはPHPのいずれからのものであるかは関係ありません。プログラミング言語はコンピューターに対応していません。プログラマーに対応しています。
一部のプログラミング言語は他のプログラミング言語よりも実行速度が遅くなりますが、何か問題があるからとは限りません。多くの場合、それは彼らがそうでなければプログラマーがしなければならないであろうより多くのことをするからです（すなわち、メモリ管理）、そしてこれらのことをすることによって、彼らは彼らがすることになっていることに優れています-プログラマーに奉仕します。
では、プログラミング言語のパフォーマンスの低下は本当に悪いことなのでしょうか？
私はそれが自動的に悪いとは思わない。 PythonはC++よりも低速ですが、両方が十分に速いの場合、Pythonが当面の問題にとって最良の選択である可能性があります遅いの場合。
それは常にトレードオフです。小さな1回限りのタスクの場合、同じことを行うC++アプリよりもPythonスクリプトを書く方がはるかに高速です（私にとっての典型的な例は、ある種のバッチテキスト処理やディレクトリのウォークです）ツリーを作成してファイルに対して何かを行う）、そして100倍遅くても、書き込みとテストに半分の時間しかかからないので、10ミリ秒と1000ミリ秒のどちらをとってもかまいません。
もちろん、PythonがC++と同じくらい高速だったとしたら、それはいいことです。その意味で、「遅い=悪い」というあなたの発言には同意します。 （たとえば、std :: vectorを使用して）トレードオフをいつ行うかを決定できる限り、いくつかのこと（たとえば、生の配列に対する配列の境界のチェック）を行わないことで、できるだけ速く.
かなりシンプル-遅いことは悪いことです
whenプログラムは特定のレベルのパフォーマンスを必要とします
理由そのパフォーマンスなしでは、要件を満たしていません。
これは、許容可能な時間内にクエリを処理する必要があるビジネスアプリケーションから、任意の時点で多くの情報を画面に表示する必要があるゲームまで、さまざまです。プログラムが十分に高速でない場合は、だけでは機能しません。
このように見てください。コンピュータは愚かです。彼らは、トリガーテーブルを備えたすべてのバカが従うことができる指示にずうずうしく従います。彼らはあなたが何を意味するかではなくあなたが言ったことを頑固に主張します。自己指示や直感の断片ではありません。ひどいです。
コンピューターが行っていることの1つは、高速です。本当に！ファイリングキャビネットを備えたナックルヘッドは、データベースと同じ仕事をすることができます。印刷機をクランクする人も、Apacheの機能を実行できます。マジで！そして実際には、彼らは何百年もの間、DIDを行いました。コンピュータが何にでも適しているのはその速度です。
したがって、（他の言語と比較して）利用に失敗したプログラミング言語は、コンピューターを使用するという唯一の利点を欠いています。
プログラミング言語は非常に高レベルで、「多くのことを行う」ことができますが、それでも非常に高速です。 OCamlはPHPよりも高水準の言語ですが、Cとほぼ同じ速さでコードを生成します。JavascriptはPHPと同じくらい動的ですが、非常に高速に実行できます。したがって、それは主に言語実装の問題であり、デザインではありません。動的言語を効率的に実装することは困難ですが、不可能ではありません。
速度は、ランタイム、初期開発時間、およびメンテナンス時間（問題/バグを引き継ぎ、新しいコードを生成してデプロイするのにかかる時間）で測定できます。
システム全体を再構築することなく、また場合によっては停止して再起動することなく、迅速な変更と展開を行えることが多いため、スクリプト言語の実行時間は一般に遅くなりますが、メンテナンス時間は速くなります。
したがって、多くは、必要な速度に応じてバランスです。
コンテキストも重要です。 0.1秒ではなく0.5秒かかって初期構成をロードすることは大したことではありませんが、実行時に0.1秒ではなく0.5秒でクエリを実行するのは、100個のクエリを処理する必要がある場合、大きな問題になる可能性があります。 10。
シンプル-高速なソフトウェアが大好きです。実際、コンピュータの主な目的は迅速に計算することです。
遅いのは相対的です。ポートを毎秒10回読み取る必要がある場合、それを実行できるバイナリを作成できない言語はtoo遅いです。サーバーとブラウザー/クライアント間の要求/応答シーケンスが秒単位で測定され、ユーザーがボタンをクリックする前に画面上で数分を費やす可能性があるWebアプリケーションを作成している場合、要求処理を処理できるプログラミング言語おそらく1秒で十分高速です（もちろん、ほとんどの場合ははるかに高速です）。
もちろん、プログラミング言語は実行速度を決定する要因になるかもしれませんが、それは言語そのものではなく、コンパイラーやランタイムに付属しているランタイムです。これは、Javaの開発を見ると明らかです。JVMのパフォーマンス（同一のハードウェア環境であっても）は、何年にもわたって根本的に向上しています。そしてもちろん、どのような環境でも、非常に遅いコードを書くことは常に可能です。そのため、「C++はJavaの10倍高速である」などの主張は、どの条件がどのようにテストされたかを正確に特定および定量化しない限り、自動的に偽です。 JavaがC++より高速であるテストを作成することも同様に可能です。すべては、テストコードとして使用しているものとその実行方法に依存します。
プログラミング言語はプログラマーにサービスを提供するために存在しないため、サービスを提供するプログラムを作成するために存在しますsers。
何かを一度だけ実行するための単純な小さな個人用ツールが必要なだけの場合は、必要なだけ遅くなることがあります。ただし、ユーザーへの展開を開始すると、特に繰り返し使用する場合は、速度とスケーリングに関心があります。 （たとえば、インストーラーは遅くなる可能性があります。インストールするプログラムは遅くない方がよいでしょう。）そして、それは単なる言語ではありません。それは全体的なプログラムです。プログラムが遅いと、ユーザーは気に入らないでしょう。そして、競争がある場合、プログラムを好まないユーザーは非常に悪いことです。したがって、プログラムを（ユーザーの反応を遅くすることによって）好まないユーザーに貢献する言語は悪いものです。
私は放送メディアの制御ソフトウェアを書くチームの一員です。米国にいる場合は、お気に入りのテレビ局やラジオ局が放送されている可能性が高いです。パフォーマンスは、クライアントからよく耳にするものの1つです。もともとは単一ステーションでの運用を目的として作成されましたが、現在は数百のチャネルを持つ主要な放送およびケーブルネットワークに署名しており、規模が問題になり始めています。私たちが彼らのために物事を速く実行することができない場合、彼らは数百万ドルの契約をできる人に引き受け、私たちは仕事を失うことになります。そのため、高速でコンパイルされた言語を使用し、データベース全体を最適化しています。
速いほど良いからです。時は金なり。サーバーソフトウェアを作成し、より遅いプログラミング言語を使用する場合は、サーバーを追加購入します。シュリンクラップされたソフトウェアを作成する場合、より速いライバルに顧客を失うことになります。
人々が使用するあらゆる種類の永続的なソフトウェアについては、通常、それをできるだけ速くしたいと考えています。アセンブリレベルでは、市場投入までの時間が長くなりすぎて、利益が得られません。それはすべてトレードオフです。ビジネスの観点から見ると、貧しいプログラマーがC++でメモリエラーをデバッグできるようにして、さらに数か月間それを実行するほうが有利かもしれませんifこれは、製品は競合他社よりも高速です。
多くのソフトウェアでは実際に速度が重要です。遅い言語は本当に遅いので「悪い」と見なされています（Pythonは簡単に50倍から100倍遅くなる可能性があり、それは多すぎます）。
プログラマーのためにプログラミング言語が存在します。
どのようにしてこの結論に至ったのかはわかりません。私はこう言います：ソフトウェアエンジニアuseプログラミング言語を彼らのニーズに合わせます。
一部のプログラミング言語は他より遅いですが、それはそれらに何か問題があるからではありません。
これもまた不安定な発言です。ここで「遅い」という言葉を使用して、意味を定義します。遅いとは、
- 同じことを達成する最終的なプログラムは、ある言語では別の言語と比較して「遅く」実行されます。
- 最終的なプログラムの作成にかかる時間は長くなる可能性があります（そのため、「遅い」と説明する人もいます）。
頭に浮かぶこれらの2つの問題は、開発に費やされる時間とパフォーマンスの間にある種のトレードオフがある場合にも絡み合っています。
言語が遅すぎるためではなく、プログラマーが悪い仕事をしたために、ほとんどのパフォーマンスの問題が存在することを指摘しておきます。実際、選択する言語よりも、パフォーマンスに関して心配すべき多くの関連事項があります。これは、私のリストでおよそ1,203,407番目です。
他のソフトウェアと同様に、速度が遅いことは、根本的な問題/悪い設計の兆候である可能性があります。設計は確かに少し時代遅れですが、これは現在の設計原則が古く、「悪い」と見なされているという事実を損なうものではありません。
たとえば、Classic ASPおよびASP.netを例にとります。
誰かが「顧客は要件を満たし、予算内で機能するソフトウェアを愛している」とコメントしました。まあ、これは本当です-しかし、それは遅いソフトウェアにかなりの影響を与えます、そしてそれは、ほぼ定義により、遅いプログラミング言語（およびフレームワーク）とアルゴリズム、および構成を意味します。遅いプログラミング言語は、変更するのが最も難しいと思われる基盤であるという理由だけで、おそらく上記すべての中で最も重要な部分です。 Oracle DBを使用し、より多くのパフォーマンスが必要な場合は、tables/index/etcを最適化できます。簡単です。コードに貧弱なアルゴリズムがある場合は、別のコードを書くことができます。フレームワークが遅い場合、フレームワークを置き換えることができます。これは簡単ではありませんが、すべてを書き直すことなく実行できます。あなたの言語が遅すぎる場合、あなたは実質的に再び始めなければなりません。
拡大する必要があるときに、PHPが十分に速く動作するようにするために行った面倒については、Facebookを参照してください。
その他の人にとっては、「非機能的パフォーマンス要件」は、特にスケーラブルなWebアプリの場合、多くの場合、仕様に記述されています。 「要求から2秒以内にユーザーにページを表示する必要があります」という条件を満たさないと、契約が失われます（またはペナルティが支払われます）。したがって、はい、顧客は要求に応えるソフトウェアを愛しており、それらの要求は高速である必要があると言っています。（ユーザーが砂時計を見つめるのにどれだけの時間を費やすかは気にしないかもしれませんが、顧客は確かにそうします-それは莫大なコストです）。
たとえば、大規模なコールセンターでは、1秒ごとに受話プロセスを節約でき、1人のコールテイカーを「ダウンサイズ」できると決定したと言われました。それは突然本当のお金になり、上司がより速く、効率的で、より使いやすいソフトウェアを得るための大きなインセンティブになります。
プログラマーがコードをできるだけ早く書き出すことを心配することに多くの時間が費やされています（そして、ユニットテストと常にリファクタリングをしています笑）。これは、人々が考えているほど多くの要因ではないことがわかりました。あなたが自分の言語の専門家であれば、経験の浅い場合よりもはるかに速くコーディングできます。したがって、エキスパートC++開発者は、初心者よりも速くより正確にコードを記述できますPHP dev。したがって、専門家になることは「簡単な」言語を選択することよりも重要だと思います。これが私が嫌いな理由です。今日どこにでもあるように見える「クールで新しいものの書き換え」のカルト。
では、プログラミング言語のパフォーマンスの低下は本当に悪いことなのでしょうか？
他のすべてが同等であり、より速く進むことは良いことです。結局のところ、実際に結果を待つのは誰も望んでいません。その結果が完了すると、リソースを解放して他のことを行うことができます。
しかし、他のすべてが等しいわけではありません。手始めに、rightの結果、または少なくとも十分な結果を生成することも重要です。 （完全に間違った結果が許可されている場合、実際にそれらを非常に迅速に生成でき、誰にとってもまったくゼロの値になります。）少し遅い言語への変更により、正しい結果が生成される可能性が高まる場合、それは通常大きなトレードオフ。豊富なモデルのセットは通常、圧倒的に多くの明示的な詳細なしに複雑な問題を表現することを容易にするため、高レベルの言語は低レベルの言語よりも有利です。
また、通常、最初にソフトウェアを作成するコスト、必要に応じて新しい機能を追加するコスト、および基盤となるシステムの変化に応じてソフトウェアを機能させ続けるコストを管理することも重要です。高水準言語では、通常、プログラミングのターンアラウンドが速くなり、プログラミングのコストを予算内に抑えることには多くの価値があります。実際、コストを低く抑えることにより、全体としてより多くの異なることを達成できます。これは一般的に良いことです。
注意すべき最後の重要なポイントは、それが1つの言語だけを使用する必要はないであり、多くのソフトウェアシステムのコンポーネントの大部分がパフォーマンスにとって重要ではないことです。低水準言語を使用してクリティカルビット用の高性能コンポーネントを生成することは賢明ですが、重要度の低い部分を高水準言語に残しておくと（生成コストを最小限に抑えるため）、非常に賢明です。さらに、優れた低水準言語を作る機能（マシンの動作を正確に制御する機能）は、優れた高水準言語（はるかに小さい説明から詳細を推測する機能）を作る機能ではありません。正反対ですので、それらを結合し、それらを長所として使用し、弱点を回避できることは、本当に素晴らしいことです。
どのコンポーネントが高性能処理を取得する必要がありますか？最適化？ 測定それら。 プロフィールそれら。推測するのではなく、真実を見つけてください。最も効果的な場所に努力を集中します。