选择器、轮询、Netbeans 平台应用程序和性能分析解释
Selector, polling, Netbeans Platform Application and performance profiling interpretation
我一直在尝试让慢速 NBM 应用程序运行得更好。在 运行 一个分析器上，我看到大部分时间都花在 poll0() 上。
上面的前 6 个方法（按总时间（CPU）都在 sun.nio.ch.WindowSelectorImpl 或 SelectorImpl 中。
有人可以帮我解释分析结果吗？我的猜测是有太多的线程重绘太频繁了。这可能是一个合理的解释吗？
我想我应该补充一点，应用程序的编程很糟糕，并发性不佳。所以，很有可能发生了愚蠢的事情。
此外，如果有人可以指出任何关于如何在此类应用程序中找到瓶颈的读物 material，我将非常高兴。
您要求阅读 material 如何找到此类应用程序中的瓶颈。
关于如何发现瓶颈，有一个逆向的观点，就是explained here。
它背后的数学是 explained here.
您使用的探查器没有给您有用的信息，因为（请原谅军事比喻）：
"Self Time" 没有用。它不会告诉您谁调用了例程。当指挥链中的每个人都是她在那里的原因时，你不能指望所有的责任都落在士兵身上。
"Total Time"也好不了多少。它告诉您下士和中尉负有责任，但没有告诉您责任为何或如何。
"CPU Time" 没有用，除非您知道没有 I/O 或其他系统等待。如果大军整天都在等待援军的到来，你不需要知道为什么吗？
一些分析器给你一个 "call graph"，但是 this post 显示了从其中一个问题中逃脱是多么容易。如果你是将军，你必须打败所有的对手，而不仅仅是其中的一部分。
探查器所做的是测量数据。如果战斗花费的时间是您认为应有的 10 倍或 100 倍，那么测量的意义何在？你所要做的就是走出战场，看一看，看看问题所在。你不会看到它的可能性很小。
回到编程，我的建议是获取所有线程的同步堆栈跟踪。
您可以快速查看哪些人实际上在做某事（而不是闲置），并且可以查看他们在做什么以及为什么。
保证，您会看到其中至少有一个正在做您正在等待的任何事情。
如果您想要粗略的时间估计，请进行几个这样的线程转储。
我一直在尝试让慢速 NBM 应用程序运行得更好。在 运行 一个分析器上，我看到大部分时间都花在 poll0() 上。
上面的前 6 个方法（按总时间（CPU）都在 sun.nio.ch.WindowSelectorImpl 或 SelectorImpl 中。
有人可以帮我解释分析结果吗？我的猜测是有太多的线程重绘太频繁了。这可能是一个合理的解释吗？
我想我应该补充一点，应用程序的编程很糟糕，并发性不佳。所以，很有可能发生了愚蠢的事情。
此外，如果有人可以指出任何关于如何在此类应用程序中找到瓶颈的读物 material，我将非常高兴。
您要求阅读 material 如何找到此类应用程序中的瓶颈。
关于如何发现瓶颈，有一个逆向的观点，就是explained here。 它背后的数学是 explained here.
您使用的探查器没有给您有用的信息，因为（请原谅军事比喻）：
"Self Time" 没有用。它不会告诉您谁调用了例程。当指挥链中的每个人都是她在那里的原因时，你不能指望所有的责任都落在士兵身上。
"Total Time"也好不了多少。它告诉您下士和中尉负有责任，但没有告诉您责任为何或如何。
"CPU Time" 没有用，除非您知道没有 I/O 或其他系统等待。如果大军整天都在等待援军的到来，你不需要知道为什么吗？
一些分析器给你一个 "call graph"，但是 this post 显示了从其中一个问题中逃脱是多么容易。如果你是将军，你必须打败所有的对手，而不仅仅是其中的一部分。
探查器所做的是测量数据。如果战斗花费的时间是您认为应有的 10 倍或 100 倍，那么测量的意义何在？你所要做的就是走出战场，看一看，看看问题所在。你不会看到它的可能性很小。
回到编程，我的建议是获取所有线程的同步堆栈跟踪。 您可以快速查看哪些人实际上在做某事（而不是闲置），并且可以查看他们在做什么以及为什么。 保证，您会看到其中至少有一个正在做您正在等待的任何事情。 如果您想要粗略的时间估计，请进行几个这样的线程转储。