当需要对子例程进行基准测试时，相对容易地为其创建工作负载，然后循环处理该工作负载以提取统计信息。它将提供足够的信息来衡量子例程的性能。
至少在理论上。但是，在实践中，我发现与真实场景的等效性并不那么简单。
在基准测试中，子例程为“核心和中心”，它将反复循环以进行测量。在此期间，它基本上垄断了数据和指令高速缓存。这可以导致设计决策可测量地改善基准数字，尽管以膨胀的指令和数据缓存预算为代价。
一旦集成到更大的系统中，目标子例程现在就会不时地被调用，并夹在多个其他子例程之间。它不再孤单，这意味着膨胀的预算现在将与之抗衡，刷新其他子例程使用的缓存。
我很好地测量和控制数据缓存的影响。但是对于指令缓存，这是一个完全不同的问题。
在子例程是单独的综合基准中，这种影响似乎无法衡量。然而，由于这种差异，它导致无效的结论。这是一个很大的问题，使基准测试本质上毫无价值或完全误导。
除了测量整个系统的性能之外，我还没有找到解决该问题的方法。但是，当该子例程设计为可重用时，尚不清楚衡量其对单个用例的贡献是否可以代表其他任何用例。 另外，当子例程只是系统的一小部分时，要以足够的准确性提取其影响就更加困难（系统本身可能比子例程的贡献更大。）
是否有任何“良好实践”可以测量子例程的性能，同时考虑到它对（共享）指令缓存的影响？