jParserを拒否すると（Node.jsバッファーを直接操作することになります）、スクリプトが1桁高速化されます

最近の過去の数ページをめくります。



2012年5月16日、 Javascript BMP Parserブログ投稿 の RReverser は、 jParser モジュールを使用して、 コミットされているブラウザーのバイナリデータを分析することについて説明しました 。



翌日（2012年5月17日）のブログ記事 「 jParser：binary analysis works simple 」でjParserのドキュメントを翻訳し、少し後（2012年5月22日、ブログ記事「 FidonetサイトのNode.js：電子メールヘッダーをjavascriptで読み、 JAM形式で保存されています ））このモジュールを使用して彼自身の経験を共有しました（今回はブラウザではなくNode.jsで）。



≈1⅓年が経過しました...



今年（2013年）の9月12日のブログ投稿 「 javascriptの速度に不満はありますか？ - 1 年半待ってください。 「私は以前に作成したモジュールの速度に不満を表明し、楽観的な理由の1つだけを指摘しました。Node.jsのバージョン0.6 からバージョン0.10への進歩的な開発は、コードの速度を3倍にしました。



そして今日、イベントは一周しました-私はjParserの使用を完全に放棄しました。 そして、達成された結果（それの不快な面と喜びの面の両方）は注目に値することが判明しました。



あなたの印象とソースの両方をあなたと共有させてください。

---

不愉快な点はこれです。Node.jsバッファを直接操作することを支持するjParserの拒否は、必然的にコードの膨張につながります。



Githubの編集内容を見て、自分で判断することができます。 オブジェクト内の1つのプロパティでjParserが十分であるコードのどこでも（たとえば、 「 'MSGIDcrc'：ulong 」）、2つの行でバッファを処理します。

nextHeader.MSGIDcrc = _JAM.JHR.readUInt32LE(offsetJHR); offsetJHR += 4; //ulong
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、ここでは、バイナリデータから読み取られたオブジェクトのフィールドごとに、そのような書き込みを処理する必要があります。



（私のコードは、JAM形式で保存されたFidonetメールのヘッダーを読み取ります。 この形式のドキュメントを読んだことがある人なら、そのようなヘッダーに20個のフィールドがあることを既に知っています。）

---

幸いなことに、jParserを放棄すると、スクリプトが大幅に高速化されます。 Travis CIサービスを使用して、テストの実行時間を自分が行った編集と比較し、編集 後に次の結果を簡単に確認できます。

• Node.js バージョン0.6では、テストは6526ミリ秒をパスし、 コード変更 後は296ミリ秒かかります 。
  
  
• Node.js バージョン0.8では、テストは3682ミリ秒をパスし、 コード変更 後は349ミリ秒かかります 。
  
  
• Node.js バージョン0.10では、テストは2147ミリ秒で合格し、コードを変更した 後 は 233ミリ秒 で合格し ます 。

約1桁の加速！



そのような結果を達成したので、「 時間は価値があるか？ 」というサインを見ることが適切です。 「XKCDコミックストリップNo. 1205。 たとえば、2時間の努力（コードの変更）を費やし、1日5回未満で実行されるこのような関数の作業時間に1秒勝った場合、この時間は無駄になります（ 5年以上返済されるため） -そして5年後、何が良いのか、コードの関連性が問われます）。



タイピングの速度がより重要な場合は、jParserを使用します。これにより労力を節約できます。



コードの速度がより重要な場合は、jParserを放棄してください。これにより、スクリプトが高速化されます。



私のモジュールの場合、1つのエコー会議のヘッダーを読み取るときの1秒あたりの加速は非常に重要です。これは、典型的なFidonetノードで数十、そのようなエコー会議が数百、大規模なもので数百もあるためです（ 例 ）。



さようならjParser。