2

したがって、私は JavaScript コーディングに関してはかなり初心者ですが、一般的なコーディングに関しては初心者ではありません。ソースコードを書くとき、私は通常、自分のコードが実行される環境 (例えば、ある種の仮想マシン) を念頭に置いています。(1)

たとえば Java では、次のように記述します。

Foo foo = FooFactory.getFoo(Bar.someStaticStuff("qux","gak",42);
blub.doSomethingImportantWithAFooObject(foo);

オブジェクトがまさにこの場所でのみ使用されている場合でもfoo(したがって、不要な変数宣言が導入されます)。まず、上記のコードはインライン バージョンよりもはるかに読みやすいというのが私の意見です。

blub.doSomethingImportantWithAFooObject(FooFactory.getFoo(Bar.someStaticStuff("qux","gak",42));

次に、Java コンパイラ コードの最適化がこれを処理することを知っています。つまり、実際の Java VM コードは最終的にインライン化されるため、パフォーマンスに関しては、2 つの間に違いはありません。(2)

さて、私の実際の質問:
JavaScript で一般的にどのレベルのコード最適化を期待できますか?

これは JavaScript エンジンに依存すると思いますが、私のコードは多くの異なるブラウザーで実行されることになるため、最悪の場合を想定して最悪のケースを見てみましょう。適度なレベルのコード最適化を期待できますか? まだ心配しなければならないケースにはどのようなものがありますか?

(1) 優れた/最良のアルゴリズムを見つけて、よく整理されたコードを書くことは、コードの最適化よりも重要であり、パフォーマンスに大きな影響を与えることを認識しています。しかし、それは別の質問になります。

(2) ここで、最適化を行わなかった場合の実際の差は小さいことに気付きました。しかし、それは論外です。非常に効率的に最適化された機能が簡単に存在します。for100'000回呼び出されるループ内の上記のスニペットを想像してみてください。

4

3 に答える 3

4

最適化にはあまり期待しないでください。

  • 末尾再帰最適化、
  • ループ展開、
  • インライン関数
  • 等

クライアントの JavaScript は CPU の重い作業を行うように設計されていないため、最適化によって大きな違いが生じることはありません。

高パフォーマンスの JavaScript コードを記述するためのガイドラインがいくつかありますが、ほとんどは次のようなマイナーで技術的なものです。

  • eval()、などの特定の関数を使用しarguments.calleeないでください。js エンジンがハイパフォーマンス コードを生成するのを妨げます。
  • 独自のコンテナーや json パーサーなどを作成しないなど、手書きの機能よりもネイティブ機能を使用してください。
  • グローバル変数の代わりにローカル変数を使用します。
  • 配列に for-each ループを使用しないでください。
  • parseInt()ではなく使用しMath.floorます。
  • そして、jQuery には近づかないでください。

これらのテクニックはすべて経験的なものに似ており、合理的な説明が背後にある場合があります。そのため、どのアプローチが優れているかを判断するのに役立つように、時間をかけて検索するか、jsPerfを試す必要があります。

コードをリリースするときは、クロージャ コンパイラを使用して、デッド ブランチや不要な変数を処理します。これにより、パフォーマンスが大幅に向上するわけではありませんが、コードが小さくなります。

一般的に言えば、最終的なパフォーマンスは、オプティマイザーのパフォーマンスではなく、コードがどれだけうまく構成されているか、アルゴリズムがどれだけ慎重に設計されているかに大きく依存します。

上記の例を見てください (FooFactory.getFoo()とBar.someStaticStuff("qux","gak",42)は常に同じ結果を返し、 とはステートレスであり、Barとは何も変更しないと仮定します)。FooFactorysomeStaticStuff()getFoo()

for (int i = 0; i < 10000000; i++)
  blub.doSomethingImportantWithAFooObject(
      FooFactory.getFoo(Bar.someStaticStuff("qux","gak",42));

-O3 フラグを指定した g++ でさえ、そのコードを高速化することはできませBarんFooFactory。したがって、この種のコードはどの言語でも避ける必要があります。

于 2012-11-14T14:38:37.423 に答える
1

そうです、最適化のレベルは JS VM ごとに異なります。しかし！それを回避する方法があります。コードを最適化/最小化するツールがいくつかあります。最も人気のあるものの 1 つは、Google によるものです。これは Closure-Compiler と呼ばれます。Web バージョンを試すことができ、build-script などの cmd-line バージョンがあります。それ以外に、最適化について試すことはあまりありません。結局のところ、Javascript は十分に高速であるためです。

于 2012-11-14T14:15:05.747 に答える
1

一般的に、コードを本当に汚く扱っていない限り (すべての var をグローバル スコープのままにしておく、多数の DOM オブジェクトを作成する、最適でないデータソースに対して高価な AJAX 呼び出しを行うなど)、本当のトリックだと思います。パフォーマンスを最適化すると、実行時にロードする他のすべてのものを管理することになります。

数十の画像に数十の画像をロードしたり、巨大な背景画像をアニメーション化したり、多数のスクリプトや css ファイルを引き込んだりすることはすべて、適切に記述された適度に複雑な Javascript よりもパフォーマンスに大きな影響を与える可能性があります。

とはいえ、Google で簡単に検索すると、Javascript パフォーマンスの最適化に関するいくつかの情報源が見つかり ます。

http://www.nczonline.net/blog/2009/02/03/speed-up-your-javascript-part-4/

http://mir.aculo.us/2010/08/17/when-does-javascript-trigger-reflows-and-rendering/

これらのリンクのうちの 2 つが指摘しているように、ブラウザーで最もコストのかかる操作はリフロー (DOM 操作のためにブラウザーがインターフェイスを再描画する必要がある場合) であるため、パフォーマンスに関して最も慎重になる必要がある場所です。 . その一部は、その場で変更するものを賢くすることで軽減できます（たとえば、インラインスタイルをアドホックに変更するよりもクラスを適用する方が安価です）。そのため、懸念事項（スタイルとデータ）を分離することが非常に重要になります.

仕事を終わらせるために必要な変更だけを行います(つまり、ページのチャンク全体を AJAX 呼び出しで置き換える "HULK SMASH (DOM)!" メソッドを実行する代わりに、リモート ソースをスクリーン スクレイピングする代わりに、 JSON データが必要な最小数の要素のみを更新するため) および他の常識的なアプローチにより、for ループの微調整に何時間も費やすよりもはるかに遠くまで到達できます (ただし、繰り返しになりますが、常識によってかなり遠くまで到達できます。それも）。

幸運を！

于 2012-11-14T14:36:25.477 に答える