
最近の過去の数ページをめくります。
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;
そして、ここでは、バイナリデータから読み取られたオブジェクトのフィールドごとに、そのような書き込みを処理する必要があります。
(私のコードは、JAM形式で保存されたFidonetメールのヘッダーを読み取ります。
この形式の
ドキュメントを読んだことがある人なら、そのようなヘッダーに20個のフィールドがあることを既に知っています。)
幸いなことに、jParserを放棄すると、スクリプトが大幅に高速化されます。
Travis CIサービスを使用して、テストの実行時間
を自分が行っ
た編集と比較
し、編集 後に次の結果を簡単に確認できます。
約1桁の加速!
そのような結果を達成したので、「
時間は価値があるか? 」というサインを見ることが適切
です。 「XKCDコミックストリップNo. 1205。 たとえば、2時間の努力(コードの変更)を費やし、1日5回
未満で実行されるこのような関数の作業時間に1秒勝った場合、この時間は無駄になります(
5年以上返済されるため)
-そして5年後、何が良いのか、コードの関連性が問われます)。
タイピングの速度がより重要な場合は、jParserを使用します。これにより労力を節約できます。
コードの速度がより重要な場合は、jParserを放棄してください。これにより、スクリプトが高速化されます。
私のモジュールの場合、1つのエコー会議のヘッダーを読み取るときの1秒あたりの加速は非常に重要です。これは、典型的なFidonetノードで数十、そのようなエコー会議が数百
、大規模なもので数百もあるため
です( 例 )。さようならjParser。