Clever Geek Handbook

JavaScriptパフォーマンスのベストプラクティス



Twitterで興味深いドキュメントに出会いました。

JavaScriptパフォーマンスのベストプラクティス



見出しは、WRT（Nokia Web RuntimeまたはS60用のウィジェット）のカテゴリ、つまり特定のNokiaプラットフォームを示していますが、多くの人にとって読むのは面白いと思います。 非常に便利なヒントがありますが、特に現代の開発_すべてのブラウザーの下で_の有害なものもあります。

最初はトピックリンクとして配置することを考えましたが、この記事では、この記事のいくつかの問題に注意を払います。 記事を読む価値はありますが、決してそれを究極の真実として扱わないでください。







繰り返しますが、これらのコメントは「すべてのブラウザー向けのユニバーサルプログラミング」に照らして検討する必要があります。 Symbianの開発に関しては、この記事は非常に真実である可能性があります



コメントでコメントを提案してください-最終的には最適化に関する優れた記事になるかもしれません

私自身はWikiでこの記事を編集しますが、「このページを表示したり、このアクションを実行するための十分な権限がありません。」



そもそも、この記事は本当に役立つヒントを数多く明らかにしています。

たとえば、evalの使用は避けるのが最善であり、要素を取得およびサイズ変更するときに、過剰なリフロー （要素の寸法または位置を決定する操作の使用を最小限に抑える） が表示されることがあります 。

移動中の変更を避ける


また、getElementsByTagNameを返すコンテナは実際に「ライブ」であり、次のコードによりブラウザがハングします。 

<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>Test</title> </head> <body> <div id="container"><em></em><em></em></div> </body> <script>/* Script here */</script> </html>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     


 var doc = document, ems = doc.getElementsByTagName('em'), cont = doc.getElementById('container'); for (var i = 0; i < ems.length; i++) { cont.appendChild(doc.createElement('em')); };




ただし、多くの欠点があります。



まず、間違い。 例：

evalまたはFunctionコンストラクターの使用を避ける 


 addMethod(myObj, 'methodName', function () { 'this.localVar=foo'; }); // => addMethod(myObj, 'methodName', function () { this.localVar=foo; });




起動を高速化し、スプラッシュ画面を表示するために、ブロックせずにスクリプトをロードします


script.onreadstatechange => script.onread y statechange







そして、エラーは構文的な計画ではなく、論理的なものです： 



 var elem = document.getElementById('elem').propertyOne = 'value of first property'; elem.propertyTwo = 'value of second property'; elem.propertyThree = 'value of third property' //  , .. [elem]    'value of first property',   dom- document.getElementById('elem').propertyOne = 'value of first property'; document.getElementById('elem').propertyTwo = 'value of second property'; document.getElementById('elem').propertyThree = 'value of third property';




第二に、いくつかのヒントは実際にアプリケーションを高速化しますが、意味がありません。 完全に異なるプログラムロジックがあります。

簡単に言えば、「B」の方が速いため、「A」の代わりに「B」を作成します。



例-
パフォーマンスが重要な関数内でtry-catch-finallyを使用しないでください


場合によっては、ループの内部、時には外部で例外を処理する必要があります。 これら2つの操作は、まったく異なる基礎と異なる結果を持っています。



パフォーマンスが重要な機能の導入を避ける


再び-別の結果。 配列のvar i in arr



、非常にまれな状況に適用できます。 配列に対する最も正しい反復（フレームワークで使用）： 

 for (var i = 0, len = arr.length; i < len; i++) if (i in arr) { // action }


これは配列を正しくトラバースしますが、配列は完全には満たされておらず、最新の仕様のforEachメソッドの動作に対応しています。 



 var arr = ['zero','one','two']; arr[10] = 'ten'; arr.forEach(function (elem) { console.log(elem); //  "zero, one, two, ten"   undefined  "two"  "ten" });




配列の内容がわかっていて、どの順序で移動するかが重要でない場合は、逆ループを使用できます 

 function sum (arr) { var result = 0; for (var i = arr.length; i--;) { result += arr[i]; } return result; };


私の長年のテストでは、読みやすいだけでなく、直接パスよりも高速であることが示されました。



スクリプトのコメントを最小限に抑えるようにする/長い変数名を避ける


まず、最新のブラウザの最新バージョンには、このヒントを不適切にするjitコンパイルがあります

第二に、動作中のアプリケーションでは、スクリプトが圧縮され、コメントが切り取られます。 開発中、このような最適化は意味をなしません

第三に、このコードを正しく理解するために必要なだけコメントします。 生産性にどんな影響があるとしても、それは重要ではありません。



範囲外の変数へのローカル参照を保存する


ドキュメントのキャッシュは理にかなっていますが、この例では意味がありません。 キャッシュからの読み取りは1回だけ発生します。



XMLおよびJSONの代替として、大規模なデータセットにはカスタムデータ交換フォーマットの使用を検討する


悪いアドバイス。 独自のデータ形式を可能な限り避けるようにしてください。記事にはそのような恐怖の例が示されています。 

 that.contacts = o.responseText.split("\\c"); for (var n = 0, len = that.contacts.length, contactSplit; n < len; n++) { contactSplit = that.contacts[n].split("\\a"); that.contacts[n] = {}; that.contacts[n].n = contactSplit[0]; // ... that.contacts[n].y = contactSplit[8]; }


まず、 var contacts = JSON.parse(o.responseText);



よりも書き込みにvar contacts = JSON.parse(o.responseText);





第二に、多くのブラウザでのJSON解析が組み込まれているため、「高速」フォーマットがJSONよりもはるかに遅く動作する可能性があります。 ただし、 コメントを参照してください 。

第三に、サポート中に多くの欠点があります： o.responseText



非自明なコンテンツは、サーバーとクライアントでパーサーとフォーマットコンパイラを書く必要があり、サードパーティの開発者はショックを受けます。

基本的な考え方は、そのような最適化はほとんど意味がないということです。 ほとんどの場合、多くの欠点があるため、回避する価値があります。



一般的に、読んで考えてください。 そこには興味深い有用なヒントがありますが、すべてを分析し、それを考えずに使用しないでください。 いつものように）


More articles:


All Articles