依存関係を構築したモジュールをロードしていますか?
基本的に「不明」とは「説明されていない」という意味です(詳細については確認tickprocessor.js
してください)。たとえば、GCは「scavenge、begin、...」のようなメッセージを出力しますが、それは。によって認識されませんlogreader.js
。
ファイルの解析に使用しているプロファイリングライブラリを知ることは役に立ちv8.log
ます。
アップデート
node-tick
パッケージは1年以上更新されておらず、おそらく最近のコマンドの多くが欠落していますprof
。代わりにnode-profilerを使用してみてください。これは、ノードのメンテナの1人によって作成されました。そして、絶対に最高の結果が必要な場合は、を使用してビルドする必要がありますnode-gyp
。
アップデート
node-profilerからの最新のもの(最新のタグではなく、最新のもの)v8.log
を使用して出力を解析し、結果をhttp://pastebin.com/pdHDPjzEに投稿しました。master
半分ほど下に表示されるいくつかの重要なエントリを指摘させてください。
[GC]:
ticks total nonlib name
2063 26.2%
[Bottom up (heavy) profile]
6578 83.4% c:\node\node.exe
1812 27.5% LazyCompile: ~parse native json.js:55
1811 99.9% Function: ~<anonymous> C:\workspace\repositories\asyncnode_MySQL\lib\MySQL_DB.js:41
736 11.2% Function: ~Buffer.toString buffer.js:392
したがって、すべてのスクリプトタイプの26.2%がガベージコレクションに費やされました。これは本来よりもはるかに高いです。それはに費やされる時間とよく相関しますがBuffer.toString
。その数のバッファが作成されてから文字列に変換される場合、スコープを離れるときに両方をgcする必要があります。
また、なぜそんなに多くの時間が費やされているLazyCompile
のか興味がありjson.js
ます。それ以上に、なぜjson.js
ノードアプリケーションでさえ必要になるのでしょうか?
アプリケーションのパフォーマンスを調整するのに役立つように、以下にいくつかのリンクを含めます。これらのリンクは、何をして探すべきかについての適切な指示を提供します。
基本を備えた素敵なスライドデッキ:
https ://mkw.st/p/gdd11-berlin-v8-performance-tuning-tricks/#1
最適化手法のより高度な例:http:
//floitsch.blogspot.com/2012/03/optimizing-for-v8-introduction.html
クロージャのより良い使用:http:
//mrale.ph/blog/2012/09/23/grokking-v8-closures-for-fun.html
ここで、同じ出力を達成できなかった理由について説明します。node-profilerとその提供元をビルドして使用nprof
しmaster
ても機能しない場合は、Windows上にあることと関係があると思います。GitHubにバグを報告することを検討し、彼があなたを助けてくれるかどうかを確認してください。