プログラミング言語のパフォーマンスが遅いのは本当に悪いことですか？[閉まっている]

ここに私がそれを見る方法があります。

マシンコードがあり、コンピューターが何かを実行するために必要なのはそれだけです。コンピューターはプログラミング言語を気にしません。マシンコードがPerl、Python、またはPHPのどれであるかは関係ありません。プログラミング言語はコンピューターに役立ちません。プログラマーに役立ちます。

一部のプログラミング言語は他のプログラミング言語よりも動作が遅くなりますが、それは必ずしも問題があるためではありません。多くの場合、それは、プログラマーがしなければならないこと（つまり、メモリ管理）をより多く行うためであり、これらのことを行うことにより、プログラマーにサービスを提供することになります。

それでは、プログラミング言語のパフォーマンスの低下は、本当に悪いことですか？

自動的に悪いとは思わない。PythonはC ++よりも遅いですが、両方とも十分に速い場合は、たとえ遅いとしても、Pythonは目前の問題に最適な選択肢です。

それは常にトレードオフです。小さな1回限りのタスクの場合、同じことを行うC ++アプリよりもPythonスクリプトを書く方がはるかに高速です（私の典型的な例は、何らかのバッチテキスト処理またはディレクトリツリーをたどってファイルに何かをすることです）。書き込みとテストにかかる時間が半分になる可能性があるため、100倍遅いにもかかわらず、10ミリ秒か1000ミリ秒かはあまり気にしません。

もちろん、PythonがC ++と同じくらい高速であればいいので、その意味で「遅い=悪い」というあなたの声明に同意します。しかし、私はむしろ、そのトレードオフをいつ行うかを決めることができる限り（たとえば、stdを使用して）、何もしない（たとえば、生の配列の配列境界チェック）ことで、できるだけ速く実行する強力な言語を持っています： ：ベクター）。

非常に簡単です-遅いことは悪いことです

ときプログラムは、一定レベルのパフォーマンスを必要とします

なぜならそのパフォーマンスずに要件を満たしていません。

これは、許容可能な時間内にクエリを処理する必要があるビジネスアプリケーションから、任意の時点で多くの情報を画面に表示する必要があるゲームまで、あらゆるものになります。プログラムの速度が十分でない場合、機能しません。

このように見てください：コンピューターは愚かです。彼らは、たまに、トリガーテーブルを持つバカが従うことができる指示に従います。彼らはあなたが意図したことの代わりに、あなたが言ったことを頑張って主張します。自己指示や直感の断片ではありません。恐ろしいです。

コンピューターが目的としているのは、高速です。本当に！ファイリングキャビネットを備えたナックルヘッドは、データベースと同じ仕事をすることができます。印刷機をクランキングする一部の人は、Apacheの機能を実行できます。まじで！そして彼らは何百年もの間、事実問題としてDIDをしました。コンピューターが何にでも適している理由は、その速度です。

そのため、プログラミング言語は（他の言語と比較して）悪用できず、コンピューターを使用する唯一の利点を失います。

プログラミング言語は非常に高レベルで、「多くのことを行う」ことができ、それでも非常に高速です。OCamlはPHPよりも高レベルの言語ですが、Cとほぼ同じ速度でコードを生成します。JavascriptはPHPと同じくらい動的ですが、非常に高速に実行できます。そのため、これは主に言語の実装に関する問題であり、設計ではありません。動的言語は効率的に実装することは困難ですが、不可能ではありません。

速度は、実行時間、初期開発時間、およびメンテナンス時間（問題/バグを引き継ぎ、新しいコードを生成して展開するのにかかる時間）の観点から測定できます。

通常、スクリプト言語の実行時間は遅くなりますが、メンテナンス時間は短くなります。これは、多くの場合、システム全体を再構築することなく、場合によっては停止して再起動することなく迅速な変更と展開ができるためです。

したがって、多くはあなたが必要とする速度に応じてバランスです。

コンテキストも重要です。0.1秒ではなく0.5秒かかって初期構成をロードすることは大したことではありませんが、実行時に、100秒のクエリを処理する必要がある場合、0.1秒ではなく0.5秒かかってクエリを実行するのは大したことです。 10。

シンプル-顧客は高速ソフトウェアが大好きです。実際、コンピューターの全体的な目的は、迅速に計算することです。

遅いのは相対的です。1秒間に10回ポートを読み取る必要がある場合、それを実行できるバイナリを作成できない言語は遅すぎます。私がサーバーとブラウザ/クライアント間のリクエスト/レスポンスシーケンスを数秒で測定し、ユーザーがボタンをクリックする前に画面上で数分を費やす可能性があるWebアプリケーションを書いている場合、リクエスト処理を処理できるプログラミング言語1秒でおそらく十分に高速になります（ほとんどの場合、はるかに高速です）。

もちろん、プログラミング言語は実行速度を決定する要因になるかもしれませんが、それは言語そのものではなく、それに付属するコンパイラーやランタイムです。これは、Javaの開発を見れば明らかです。JVMのパフォーマンスは（同じハードウェア環境であっても）長年にわたって劇的に向上しています。そしてもちろん、どんな環境を選んでも、ひどく遅いコードを書くことは常に可能です。そのため、「C ++はJavaの10倍高速です」などの主張は、どの条件がどのようにテストされたかを正確に特定および定量化しない限り、自動的に偽物です。JavaがC ++よりも高速なテストを作成することも同様に可能です。テストコードとして使用しているものと実行方法に依存します。

プログラマーにサービスを提供するプログラミング言語は存在しないため、ユーザーにサービスを提供するプログラムを作成するために存在します。

一度だけ何かをするためのシンプルで小さな個人用ツールが必要な場合、それはあなたが望むほど遅くなります。ただし、ユーザーへの展開を開始すると、特に繰り返し使用する場合は、速度とスケーリングが重要になります。（たとえば、インストーラーは遅くなる可能性があります。インストールするプログラムは遅くない方がよいでしょう。）そして、それは言語だけではありません。それは全体的なプログラムです。プログラムが遅い場合、ユーザーは気に入らないでしょう。そして、競争がある場合、ユーザーがあなたのプログラムを好まないことは非常に悪いことです。そのため、ユーザーのプログラムが好きではない（低速にすることで）ユーザーに貢献する言語は悪いです。

私は、放送メディア用の制御ソフトウェアを作成するチームの一員です。米国にいる場合は、お気に入りのテレビやラジオ局が実行されている可能性があります。パフォーマンスは、クライアントからよく耳にするものの1つです。もともとは小規模な単一ステーションの運用向けに作成されていましたが、現在では数百のチャンネルを持つ主要な放送およびケーブルネットワークに署名しており、規模が問題になり始めています。私たちが彼らのために物事を速く走らせることができなければ、彼らは数百万ドルの契約をできる人に引き継ぐでしょう、そして私たちは仕事を失います。そのため、高速でコンパイルされた言語を使用し、データベースを完全に最適化します。

速いほど良いからです。時は金なり。サーバーソフトウェアを作成し、より遅いプログラミング言語を使用する場合、より多くのサーバーを購入します。シュリンクラップされたソフトウェアを書くと、より速いライバルに顧客を失うことになります。

人々が使用する永続的なソフトウェアの種類については、通常は可能な限り高速にしたいと考えています。アセンブリレベルでは、市場投入までの時間が非常に長くなるため、利益がありません。すべてのトレードオフです。ビジネスの観点から見ると、貧しいプログラマーがC ++でメモリエラーをデバッグできるようにすると、製品が競合他社よりも高速であるという意味で、さらに数か月間行うことができます。

そのため、多くのソフトウェアでは実際に速度が重要です。遅い言語は、実際には遅すぎるため、「悪い」と見なされています（Pythonは簡単に50倍から100倍遅くなりますが、それは大きすぎます）。

プログラマーに役立つプログラミング言語が存在します。

どうやってこの結論に至ったのか分かりません。私は言う：ソフトウェアエンジニアが使う自分のニーズのためのプログラミング言語を。

一部のプログラミング言語は他のプログラミング言語よりも遅いですが、それはそれらに何か問題があるからではありません。

これはまた、控えめな文です。ここで「遅い」という言葉を使用して、意味を定義します。遅いとは次のことを意味します。

1. 同じことを実現する最終プログラムは、ある言語で他の言語と比較して「遅い」動作をします。
2. 最終プログラムの作成にかかる時間が長くなる可能性があります（したがって、「遅い」と説明する人もいます）。

思い浮かぶこれらの2つの問題は、開発とパフォーマンスに費やされる時間の間に何らかのトレードオフがある場合にも絡み合っています。

他のソフトウェアと同様に、低速であることは、根本的な問題/設計の誤りの兆候です。確かにデザインはちょっとした精神論者ですが、これは現在のデザイン原則が古く、「悪い」と考えられているという事実を損なうものではありません。

たとえば、クラシックASPとASP.netを取り上げます。

ある人は、「顧客は要件を満たし、予算内で機能するソフトウェアを好む」とコメントしました。まあ、これは本当です-しかし、それは遅いソフトウェアにかなりの関係があります、そして、それはほとんど定義上、遅いプログラミング言語（およびフレームワーク）とアルゴリズムと構成を意味します。スロープログラミング言語は、上記のすべての中で最も重要な部分である可能性があります。それは、変更が最も困難であることがわかる基盤だからです。Oracle DBを使用していて、さらにパフォーマンスが必要な場合は、tables / index / etcを最適化できます。簡単です。コードに貧弱なアルゴリズムがある場合、別のコードを書くことができます。フレームワークが遅い場合、それを置き換えることができます-それはそれほど簡単ではありませんが、すべてを書き直さなくても実行可能です。言語が遅すぎる場合は、実際にやり直す必要があります。

スケーリングが必要なときにPHPを十分高速に動作させるための手間については、Facebookを参照してください。

特にスケーラブルなWebアプリの場合、残りの部分では、「非機能パフォーマンス要件」が仕様に記載されることがよくあります。「リクエストの2秒以内にユーザーにページを表示する必要があります」を満たさないと、契約を失います（またはペナルティを支払う）。 （ユーザーが砂時計をじっと見つめる時間は気にかけないかもしれませんが、顧客は確かにそうです-それは莫大なコストです）。

例として、大規模なコールセンターで、1秒ごとに1人のコールテーカーを「縮小」できると判断したと言われました。それは突然本当のお金であり、上司がより速く、効率的で使いやすいソフトウェアを手に入れるための大きなインセンティブです。

プログラマーがコードを可能な限り高速に切り出すことを心配するのに多くの時間を費やしています（そしてユニットテストとリファクタリングを常にしています）（笑）。私は、これが人々が考えるほど多くの要因ではないことを発見しました-あなたがあなたの言語の専門家なら、あなたは経験の浅い場合よりもはるかに速くコーディングできます。そのため、熟練したC ++開発者は、初心者のPHP開発者よりも迅速かつ正確にコードを記述できます。ですから、「簡単な」言語を選ぶよりも専門家になることが重要だと思います。だからこそ、今日どこにでもあるような「クールで新しいものに書き直す」というカルトが嫌いです。

パフォーマンスの問題のほとんどは、言語が遅すぎるためではなく、プログラマーが悪い仕事をしたために存在することを指摘します。本当に、選択した言語よりもパフォーマンスに関して心配するべき多くの関連する事柄があります。それは私のリストの約1,203,407番目になります。

それでは、プログラミング言語のパフォーマンスの低下は、本当に悪いことですか？

他のすべてが平等で、高速化するのは良いことです。結局のところ、誰も実際にいくつかの結果をもっと長く待ちたくないし、その結果が完了すると、他のことのためにリソースを解放することができます。

しかし、他のすべてが同等というわけではありません。手始めに、権利を生み出すことも重要です結果、または少なくとも十分な結果です。（完全に間違った結果が許容される場合、実際にそれらを非常に迅速に生成でき、誰に対してもまったくゼロの値になります。）多少遅い言語への変更により正しい結果が生成される可能性が高くなる場合、それは通常大きなトレードオフ。高レベルの言語は、ここでの低レベルの言語よりも利点があります。通常、豊富なモデルセットにより、圧倒的に多くの詳細を明示することなく、複雑な問題を表現しやすくなります。

通常、最初にソフトウェアを生産するコストを管理し、必要に応じて新しい機能を追加し、基盤となるシステムの変更に応じて機能を維持することも重要です。高レベル言語は通常、プログラミングのターンアラウンドを高速化し、プログラミングのコストを予算内に抑えることには多くの価値があります。実際、そこにコストを抑えることで、全体としてより多くの異なることを達成できます。これは一般に良いことです。

最後に注意すべき重要な点は、1つの言語だけを使用する必要はなく、多くのソフトウェアシステムでは、コンポーネントの大部分がパフォーマンスクリティカルではないことです。低レベルの言語を使用して重要なビットの高性能コンポーネントを作成するのが賢明であり、重要度の低い部分を高レベルの言語に残すことで（それらの作成コストを最小限に抑えるため）非常に賢明です。さらに、優れた低レベル言語を作成する機能（マシンの動作を正確に制御する機能）は、優れた高レベル言語を作成する機能（非常に小さな記述から詳細を推測する機能）ではありません。正反対にあるので、それらを一緒に結合し、それらを強みのために使用し、弱点を避けることができることは、本当に素晴らしいことです。

どのコンポーネントが高性能の治療を受けるべきですか？最適化？それらを測定します。それらをプロファイルします。推測するのではなく、真実を見つけてください。最も効果のある場所に努力を集中してください。