您是否正在加载任何已构建依赖项的模块?
基本上,“未知”的意思是“下落不明”(查看tickprocessor.js
更多解释)。例如,GC 将打印诸如“scavenge,begin,...”之类的消息,但logreader.js
.
这将有助于了解您使用什么分析库来解析v8.log
文件。
更新
该node-tick
软件包已经一年多没有更新了,可能缺少很多最近的prof
命令。尝试改用node-profiler。它是由节点的维护者之一创建的。如果你想要绝对最好的结果,你需要使用node-gyp
.
更新
我已经使用node-profiler中的最新版本(最新版本,而不是最新标签)解析了v8.log
输出,并将结果发布在http://pastebin.com/pdHDPjzEmaster
请允许我指出几个出现在一半左右的关键条目:
[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'd。
我也很好奇为什么要花这么多时间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 上提交一个错误,看看他是否会帮助你。