我假设这对于同一台计算机中的同一段代码总是相同的，并且不受其他进程的影响
这不是计算机的工作方式。代码在很大程度上受到机器上运行的其他进程的影响。一台典型的Windows机器大约有1000个活动线程，你可以在Taskmgr.exe的性能选项卡中看到这个数字。它们中的绝大多数都处于休眠状态，等待Windows发出的某种事件信号。然而，如果机器正在运行代码，包括你的代码，这是准备去和采取CPU时间，那么Windows将给予他们所有的一片馅饼。
这使得测量你的代码所花费的时间量是一个相当随意的测量。你唯一能估计的是所花费的最小时间量。你可以通过运行测试几十次来实现这一点，你得到一个不受其他进程影响的样本的可能性很大。然而，这在真实的生活中永远不会发生，你最好把 * 中位数 * 值作为一个现实的性能测量值。
唯一真正有用的测量方法是测量算法的 * 增量 * 改进。更改代码，看看中值时间如何因此而变化。

基本上是多少周期CPU花费.我假设这将始终是相同的同一段代码在同一台计算机上，而不是由其他进程的影响.可能有一些基本的东西，我在这里失踪，如果是这样，请启发我的意见或答案.
函数使用的CPU时间是一个非常模糊的概念。

• 它是否包括在调用树中其下任何位置执行的I/O？
• 是只有“自我时间”还是包括被调用者？（在严格的代码中，自我时间通常大约为零。）
• 它是所有调用的平均值吗？定义“所有”。
• 谁使用这些信息，出于什么目的？是为了找到所谓的“瓶颈”？还是只是为了某种回归跟踪的目的？

如果目的不仅仅是度量，而是找到值得优化的代码，我认为一个更有用的概念是 * Percent Of Time On Stack *。收集该信息的一个简单方法是在随机的挂钟时间（在您关心的时间间隔内）读取函数调用堆栈。这具有以下属性：

• 它表示包含时间百分比。
• 它给出了行级（而不仅仅是函数级）百分比，因此它可以精确定位代价高昂的代码行，无论它们是否是函数调用。
• 它包括I/O和CPU时间（在严肃的软件中，排除I/O时间是不明智的，因为你真的不知道调用树中几层以下的东西在花费时间）。
• 它对其他进程对CPU的竞争或CPU速度相对不敏感。
• 它不需要高采样率或大量的样本来找到昂贵的代码。（这是一个常见的误解。）测量精度的每一个额外的数字需要大约100倍的样本，但这并不能更精确地定位昂贵的代码。

Zoom是一个基于此原则的分析器。
另一方面，如果目标只是测量，那么用户可以看到更改是否有助于或损害性能，那么CPU环境需要控制，我建议使用简单的整体时间测量。

测量CPU时间的最佳方法是使用指令“rdtsc”或“读取时间戳计数器”。（CPU本身的一部分）以CPU的内部时钟速度递增。因此，两个读数之间的差异是经过的时钟周期数。如果（代码）不是太高级（虽然不太确定）。你可以测量磁盘上的时间，网络上的时间，时间在CPU等-可能性是无穷无尽的。如果你除以你的CPU的时钟周期数-例如，以兆赫为单位的速度，你将得到微秒的运行次数。这是相当好的精度，而且可能会更好。考虑构建一个GUI，它与CPU使用统计数据接口。
在您的环境的帮助文件中搜索“rdtsc”或“rdtsc”或“_rdtsc”。