java，时间单独的 if 语句和循环而不是带有探查器的方法
java, time individual if statements and loops rather than methods with profiler
我使用 VisualVM 之类的工具来分析我的方法，以找到缓慢的方法来返工以使其更快，但我似乎找不到任何分析器来对方法内的单个循环或代码块进行计时。
现在我不得不求助于手动计时>
long sTime = System.currentTimeMillis();
//my Code here
System.out.println("time=" + ((System.currentTimeMillis() - sTime)));
但这真的很乏味，因为我必须始终为每个 loop/if/codeblock 手动添加和删除计时器以获得细粒度的计时数据。我想知道是否有任何工具可以分析代码块或某种 eclipse 插件可以自动执行添加和删除计时器的过程。我使用过代码模板，但它远非完美。
我相信我不是唯一想要更优雅的细粒度分析解决方案的人。
为了编写微基准测试，您应该使用合适的工具，例如 JMH. Using the right tool for benchmarking also allows you to avoid the common pitfalls。
您说（实际上）您想了解如何使您的代码 运行 更快。
这是大多数人想要做的。
有一个简单的方法，根本不需要分析器。
如果您的代码正在做一些不需要做的事情并且您摆脱了那件事，那么您的代码在相同的硬件上只能 运行 更快。没有别的办法了。
删除它（让我们称之为 K）将节省一些时间。假设它是 30%。
这意味着如果你有办法获得随机时间堆栈样本，比如 jstack 或者简单地在调试器中暂停它并显示堆栈（也许还有一些数据），该样本在 K 期间有 至少 30% 的机会。"at least" 因为它实际上可能花费 50% 的时间，而修复只节省 30%。
如果你这样做 10 次，你可以期望看到 K 大约 3 次（或更多）。
如此做 10 次。
每个堆栈示例都会向您展示堆栈上的每个函数和代码行，如果您阅读它，您将及时充分了解它在做什么以及为什么这样做。
在那里寻找任何东西，在堆栈的任何级别，可以做得更好。
如果您看到一件可以做得更好的特定事情，并且您在 多个样本 上看到它，您就找到了 K.
事实上，它的百分比越大，您需要多次查看的样本就越少。
修复它，然后使用您的计时器查看结果。
然后你可以重新做一遍，以获得下一个加速。
当你再也找不到的时候，你的代码基本是最优的。
这可能会令人惊讶，但这可以找到任何分析器可以找到的任何加速，而有些则不能。
它被称为random pausing，很多人都依赖它。
有些人说这就是剖析器所做的，只会更好，但他们需要考虑一下。
即使是在挂钟时间以行级精度对堆栈进行采样的优秀分析器的问题是它们有一个总结的后端 - 热路径、调用图、火焰图、"total time"、"self time" ... 随便。
我们鼓励您查看它，而不是实际样本本身。
This post 显示加速隐藏这些摘要是多么容易，以及为什么这是一件坏事。
样本是洞察力所在，它告诉您正在发生的事情可以做得更好，如果需要足够的时间来修复，则不需要大量的样本才能看到它。
如果您想知道为什么，the math is here.
回复评论：
您走在正确的轨道上。你知道它在无限循环或接近无限循环上工作，因为这样的问题占用了 99.99% 的时间，所以你的停顿肯定会落在其中。如果问题花费的时间较少，例如 30% 甚至 10%，它也有效。
如果这个问题花费了 F 分之一的时间，那么您平均每 1/F 个样本就会看到它。
例如，如果 F 为 0.3 (30%)，那么平均每 1/0.3 = 3.33 个样本就会看到它。
但是，如果您只看到一些可疑代码一次，那并不意味着它有问题。
但是如果你看到它两次（或更多）那么你肯定知道这是一个获得加速的机会。
两次看到一个问题所需的平均样本数是 2/F，或者如果 F 是 30%，则需要 6.67 个样本。
所以继续取样，直到你两次看到一些可疑代码。
如果您的代码 运行 速度太快，没问题。只需在它周围放置一个长 运行ning 循环。假设如您所说，需要 3 微秒。您所要做的就是循环 10^7 次，这将需要 30 秒。
如果有一个加速的机会在那里占用了 30% 的时间，那么每次暂停都会有 30% 的机会显示它，无论它有多快。
您无需担心代码速度太快。
您想节省大约 70% 的时间。可能需要多次修复才能做到这一点。假设有 30%、20%、10% 和 10% 的潜在加速。去掉 30% 的那个，其他的分别扩大 1.43 到 29%、14% 和 14%。去掉29%，现在分别是20%和20%。去掉下一个，最后一个是25%。这就是您获得大幅加速的方式 - 通过剥离。
下面是最重要的一点：
由此可见不错过一个是多么重要。
只得到四分之三，漏掉一个，不会削减芥末。
Speedup opportunities can easily hide from profilers' summaries，但他们无法对您查看堆栈示例进行隐藏。
忘记所有花哨的分析器结果，你需要速度，这是底线。
我使用 VisualVM 之类的工具来分析我的方法，以找到缓慢的方法来返工以使其更快，但我似乎找不到任何分析器来对方法内的单个循环或代码块进行计时。
现在我不得不求助于手动计时>
long sTime = System.currentTimeMillis();
//my Code here
System.out.println("time=" + ((System.currentTimeMillis() - sTime)));
但这真的很乏味，因为我必须始终为每个 loop/if/codeblock 手动添加和删除计时器以获得细粒度的计时数据。我想知道是否有任何工具可以分析代码块或某种 eclipse 插件可以自动执行添加和删除计时器的过程。我使用过代码模板，但它远非完美。
我相信我不是唯一想要更优雅的细粒度分析解决方案的人。
为了编写微基准测试，您应该使用合适的工具，例如 JMH. Using the right tool for benchmarking also allows you to avoid the common pitfalls。
您说（实际上）您想了解如何使您的代码 运行 更快。 这是大多数人想要做的。 有一个简单的方法，根本不需要分析器。
如果您的代码正在做一些不需要做的事情并且您摆脱了那件事，那么您的代码在相同的硬件上只能 运行 更快。没有别的办法了。
删除它（让我们称之为 K）将节省一些时间。假设它是 30%。
这意味着如果你有办法获得随机时间堆栈样本，比如 jstack 或者简单地在调试器中暂停它并显示堆栈（也许还有一些数据），该样本在 K 期间有 至少 30% 的机会。"at least" 因为它实际上可能花费 50% 的时间，而修复只节省 30%。
如果你这样做 10 次，你可以期望看到 K 大约 3 次（或更多）。
如此做 10 次。
每个堆栈示例都会向您展示堆栈上的每个函数和代码行，如果您阅读它，您将及时充分了解它在做什么以及为什么这样做。
在那里寻找任何东西，在堆栈的任何级别，可以做得更好。
如果您看到一件可以做得更好的特定事情，并且您在 多个样本 上看到它，您就找到了 K.
事实上，它的百分比越大，您需要多次查看的样本就越少。
修复它，然后使用您的计时器查看结果。
然后你可以重新做一遍，以获得下一个加速。
当你再也找不到的时候，你的代码基本是最优的。
这可能会令人惊讶，但这可以找到任何分析器可以找到的任何加速，而有些则不能。
它被称为random pausing，很多人都依赖它。
有些人说这就是剖析器所做的，只会更好，但他们需要考虑一下。
即使是在挂钟时间以行级精度对堆栈进行采样的优秀分析器的问题是它们有一个总结的后端 - 热路径、调用图、火焰图、"total time"、"self time" ... 随便。
我们鼓励您查看它，而不是实际样本本身。
This post 显示加速隐藏这些摘要是多么容易，以及为什么这是一件坏事。
样本是洞察力所在，它告诉您正在发生的事情可以做得更好，如果需要足够的时间来修复，则不需要大量的样本才能看到它。
如果您想知道为什么，the math is here.
回复评论：
您走在正确的轨道上。你知道它在无限循环或接近无限循环上工作，因为这样的问题占用了 99.99% 的时间，所以你的停顿肯定会落在其中。如果问题花费的时间较少，例如 30% 甚至 10%，它也有效。
如果这个问题花费了 F 分之一的时间，那么您平均每 1/F 个样本就会看到它。 例如，如果 F 为 0.3 (30%)，那么平均每 1/0.3 = 3.33 个样本就会看到它。 但是，如果您只看到一些可疑代码一次，那并不意味着它有问题。 但是如果你看到它两次（或更多）那么你肯定知道这是一个获得加速的机会。 两次看到一个问题所需的平均样本数是 2/F，或者如果 F 是 30%，则需要 6.67 个样本。 所以继续取样，直到你两次看到一些可疑代码。
如果您的代码 运行 速度太快，没问题。只需在它周围放置一个长 运行ning 循环。假设如您所说，需要 3 微秒。您所要做的就是循环 10^7 次，这将需要 30 秒。 如果有一个加速的机会在那里占用了 30% 的时间，那么每次暂停都会有 30% 的机会显示它，无论它有多快。 您无需担心代码速度太快。
您想节省大约 70% 的时间。可能需要多次修复才能做到这一点。假设有 30%、20%、10% 和 10% 的潜在加速。去掉 30% 的那个，其他的分别扩大 1.43 到 29%、14% 和 14%。去掉29%，现在分别是20%和20%。去掉下一个，最后一个是25%。这就是您获得大幅加速的方式 - 通过剥离。
下面是最重要的一点： 由此可见不错过一个是多么重要。 只得到四分之三，漏掉一个，不会削减芥末。 Speedup opportunities can easily hide from profilers' summaries，但他们无法对您查看堆栈示例进行隐藏。 忘记所有花哨的分析器结果，你需要速度，这是底线。