3

私は過去数か月間、多くの SVG を使用し、一般的に多くの要素を含むプロトタイプ ページを構築してきました。また、JavaScript とサーバーサイド (大量の AJAX) の両方で大量のデータが処理されています。ページには何千ものイベント リスナーがあります。かなり重いのがポイントです。

JS でこのようなことを行う際の最大のハードルの 1 つは、シングル スレッドであることです。これは、たとえば 10 秒間の計算を実行する必要があるときにページをロックします。これを改善するための戦略はいくつかありますが、IE で Web ワーカーがサポートされるまでは、洗練された解決策はあまりありません。また、ページは 500MB 以上のメモリを使用できますが、これは Chrome が時々苦労しているようです.

私が疑問に思っているのは、このようなものを JavaScript で構築することの実現可能性です。私のコードは最適化にはほど遠いですが、このページが現在処理している負荷が必要なだけであると仮定しましょう。

また、ユーザーがアプリケーションを使用するには、少なくともミッドレンジのデスクトップが必要になると仮定しましょう。

人々は JavaScript をこれほどまでに推し進めているのでしょうか? メモリと CPU のパフォーマンスに関して、期待できる処理の限界は何ですか? クライアント側とサーバー側でどの程度の作業を行う必要がありますか?

編集: 誰もが質問を誤解することは避けられなかったと思います. JS コードを最適化する方法についてアドバイスを求めているわけではありません。client で処理するのに妥当な処理とデータの量を尋ねています。はい、これはハードウェアに依存しており、最新のブラウザーを備えたミッドレンジのデスクトップと言って答えようとしましたが、それは重要ではありません。重い処理を行うのに JavaScript がどれほど強力かを概念的に知りたいです。JavaScript で重い処理を行うことはまったく実行可能ですか?

みんなが今それを手に入れることを願っています。これは、サーバー側とクライアント側の比率です。1000000回の繰り返しでループを実行する必要があり、JSでX回の繰り返しを実行するか、サーバーでY回の繰り返しを実行するかを選択する際にコストがないと仮定すると、JavaScriptが処理することを期待するのはどれくらい合理的ですか?

4

3 に答える 3

4

1) 確かに、何千ものイベント リスナーは、イベント バブリングによって統合できます。さまざまなイベント ターゲットに対してさまざまなサブルーチンを持つ 1 つのマスター イベント ハンドラーを使用すると、多数の特定のハンドラーよりもパフォーマンスが向上します。

2) 「Web ワーカーが IE でサポートされるまでは、洗練されたソリューションはあまりありません。」

反対に、ブラウザのフリーズは、処理を小さなチャンクで実行し (可能であれば、コールバックごとに 100 ミリ秒未満に保つようにします)、タイムアウト後に次のステップを実行することで軽減できます。ブラウザーは、その状態を更新し、ユーザー入力を処理する機会を与えられます。

3) 膨大な数の要素がある場合、SVG よりもHTML5 Canvas要素の方が適切なソリューションのように思えます。

4) 「私のコードは最適化されていません」

このように限界を押し広げている場合、アルゴリズムの最適化はすべての違いを生みます。

5) DOM アクセスは非常にコストがかかるため、DOM 操作の数を巧みに最小限に抑えることで、大きな利益を得ることができます。一度に 1 つずつ、各要素に触れていないことを確認してください。混乱全体を再構築し、1 回の DOM 操作ですべてを置き換えることをお勧めします。

于 2012-04-19T02:53:33.573 に答える
0

直面する可能性があり、実際には何もできないハードルは、ユーザーが使用するシステムです。512MB の RAM で Pentium を実行しているユーザーにとっては、IE6 の損傷に侮辱を加えるために、webapps はグラインドします。もう 1 つの問題は、ブラウザ自体です。DOM は遅いです。DOM にはできるだけ触れないようにする必要があります。

できることは、コードを改善し、メモリを消費している箇所や過剰な処理を行っている箇所を見つけて分解することです。たとえば、現在、シングル スレッド化は、タイムアウトとコールバックを使用して修正できます。これは、非常に長いループを処理する私のデモの1 つです。1 つは同期操作を行い、もう 1 つはタイムアウトを使用して非同期操作をシミュレートします。

データと処理をサーバーにオフロードして、クライアント側アプリを「シン クライアント」にすることもできます。HTTP リクエストはあなたを殺すかもしれませんが、アプリで何か他のことをしている間、サーバーを「2 番目のスレッド」として扱います。たとえば、ゲームのように。サーバー上のスコア、ランキング、対戦、すべてを計算します。クライアント側にそれをさせないでください。クライアントを、サーバーで起こっているすべてのことの「ディスプレイ」にするだけです。

于 2012-04-19T01:56:17.813 に答える
0

石に書かれた制限はありません。

私のコンピューターと、レシピを検索するマシンと、4歳のネットブックでできることは異なります. メモリ、速度などは、ブラウザ、CPU、RAM、およびマシンで実行されている他のものに依存します。他のプラットフォームでコードを実行すると、コードがフリーズし、プロセスを強制終了するために 3 本の指で敬礼する必要があるに違いありません。

  • スマートなイベント処理を行い、すべての要素ではなく、より低いレベルでクリックを検出します。
  • 集中的な処理のためにサーバーにできるだけプッシュします。
  • コードを最適化します。ループの繰り返しごとに画面を更新していないことを確認してください。
  • 可能な場合は、http リクエストを結合/最小化します。
于 2012-04-19T02:32:39.323 に答える