-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dfsTraverse 性能提升 #1
Comments
可考虑只测量 dfsTraverse 的性能,而不是 buildIdCache,因为 buildIdCache 可能哈希就占了大头。 |
使用 jmh 重新进行了性能测试,比较下面两种 dfsTraverse 谁更高效: def dfsTraverse(e: Element): Iterator[Element] = Iterator.single(e) ++ getChilds(e).flatMap(dfsTraverse)
def dfsTraverse(e: Element): Iterator[Element] = if (e.childNodeSize() == 0) Iterator.single(e) else Iterator.single(e) ++ getChilds(e).flatMap(dfsTraverse) 第一感觉似乎第二种更好,而且对 gc 也更友好。但测量结果表明并不是这样。 第一种实现的 3 次结果:
第二种实现的 4 次结果:
运行时间方面第一种似乎更优,而 gc 方面则看不出差别。 |
上面是 -i 10 的结果,如果用 20 次的话: jmh/run -i 20 -wi 10 -f1 -t1 -prof gc 第一种:
第二种:
似乎终于可以看出结果了:第一种速度更快,第二种 gc 次数更少。 |
又想到一招:将递归改为非递归。非递归的 DFS 参考 https://en.wikipedia.org/wiki/Tree_traversal |
jmh 运行结果,dfsTraverse 6x 提升:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
线上用 VisualVM sampler 发现 Iterator 的某个匿名中的 Iterator 的 hasNext 占用 CPU 较高。故考虑优化一下 dfsTraverse 中的 Iterator 使用。
采用 ScalaMeter
The text was updated successfully, but these errors were encountered: