我想收集我的代码的特定例程的度量标准，以查看我可以最佳优化的位置。我们举一个简单的例子，说我有一个包含多个“学生”的“班级”数据库。比方说，当前的代码为每个学生调用数据库，而不是一次一批地抓取它们。我希望看到每次到数据库的行程需要多长时间才能完成每个学生行。特定例程的性能指标：任何最佳实践？
这是C＃，但我认为它适用于任何地方。通常，当我对某个特定例程的性能感到好奇时，我会在运行之前创建一个DateTime对象，运行该例程，然后在调用之后创建另一个DateTime对象，并在两者之间花费毫秒差异来查看它运行多长时间。通常我只是在页面的跟踪中输出这个...所以它有点低保真。任何最佳实践？我曾想过能够将Web应用程序置于某种“诊断”模式下，并使用我之后的任何内容进行详细的日志记录/事件日志写入，但我想看看stackoverflow配置单元是否有更好的主意。
有时你会采取的方法会让你看看你的应用程序的性能。 我可以推荐的一件事是使用System.Diagnostics.Stopwatch而不是DateTime， DateTime只能精确到16毫秒，其中Stopwatch准确到cpu tick。
但我建议使用自定义性能计数器来补充它，以便在开发过程中生成和运行应用程序。
我使用这种方法，我认为它非常准确。
我偶尔会使用这种方法，并发现它相当准确。问题在于，在大量应用程序中使用相当多的调试日志时，通过日志搜索这些信息可能会很痛苦。所以我使用外部工具（我主要使用Java进行编程，并使用JProbe），这些工具允许我查看我的方法的平均时间和总时间，仅由特定方法花费多少时间（与此方法花费的累积时间相反以及它调用的任何方法）以及内存和资源分配。
这些工具可以帮助您衡量整个应用程序的性能，如果您在性能很重要的领域进行大量开发，您可能需要研究可用工具并学习如何使用它们。
对于数据库查询，你有两个小问题。缓存：数据缓存和语句缓存。
如果您运行查询一次，语句将被解析，准备，绑定和执行。数据从文件中提取到缓存中。
当您再次执行查询时，会使用缓存，性能通常要好很多。
哪个是“真实”的表现数字？第一个还是第二个？有些人认为“最坏的情况”是真正的数字，我们必须优化。其他人说“典型案例”，并运行查询两次，忽略第一个。其他人说“平均”，并运行30次，平均所有。其他说“典型的平均”，运行31次，平均过去30次。
我建议“31最后30”是最有意义的DB性能数字。不要为无法控制（解析，准备，绑定）时间的事物出汗。汗水的东西，你可以控制 - 数据结构，I/O加载，索引等。
有一些Profilers可用，但坦率地说，我认为你的方法更好。分析器的方法是矫枉过正的。如果你完全不知道瓶颈在哪里，也许使用轮廓仪是值得的。我宁愿花一点时间分析问题，并提出一些策略性的打印语句，而不是找出如何对应用程序进行性能分析，然后倾注庞大的报告，其中每个可执行代码行都是定时的。
如果您使用.NET，那么我建议您查看Stopwatch课程。您从中获得的时间将比使用DateTime的同等样本准确得多。
我还建议您检查ANTS Profiler以了解性能异常重要的情况。
我认为你有一个好方法。我建议您在日志文件中生成“机器友好”记录，以便您可以更轻松地解析它们。类似CSV或其他分隔的结构一致的记录。
值得考虑投资一个好的商业分析器，特别是如果你曾经期望再次这样做。
我使用的这个函数JProfiler适用于Java世界，可以附加到已经运行的应用程序，因此不需要特殊的工具（至少对于更新的JVM）。
它非常快速地在您的代码中构建了一个排序的热点列表，显示了您的代码花费了大部分时间内的哪些方法。它在默认情况下非常智能地进行过滤，并允许您在需要时进一步调整过滤，这意味着您可以忽略第三方库的细节，同时挑选那些一直在使用的方法。
此外，您还会获得许多有关您的代码正在执行的其他有用报告。它在我第一次使用它时保存了许可证的费用;我不必添加大量的日志记录语句，并构建一个机制来支持输出：分析器的开发人员已经为我完成了所有这些工作。
我不以任何方式与ej-technologies联系在一起，除非是一个非常开心的客户。
当我在Eclipse中开发一个程序时，我只是在执行所需函数之前和之后输出控制台的时间（以毫秒为单位）。 – 2008-11-13 15:54:25
当我测试代码的有限部分时，我也会这样做。但它并没有告诉你如何花费时间。如果该函数调用其他函数，那么知道哪些函数是昂贵函数会很有用。 – Elie 2008-11-13 15:57:32