对于复杂的算法,您如何衡量其性能？

我们现在假设您缩小了应用中典型瓶颈的位置.如您所知,可能是您为重新索引表而运行的批处理过程; 它可能是运行在有效日期树上的SQL查询; 它可能是几百个复合对象的XML编组.换句话说,您可能会遇到以下情况:

public Result takeAnAnnoyingLongTime(Input in) {
   // impl of above
}

不幸的是,即使您已经确定了瓶颈之后,您所能做的就是消除它.没有简单的解决方案.

您如何衡量瓶颈的性能,以便了解您的修复方向正朝着正确的方向发展？

两点:

谨防臭名昭着的"优化空闲循环"问题.(例如,请参阅"保时捷在停车场"标题下的优化故事.)也就是说,仅仅因为例程花费了大量时间(如您的分析所示),不要认为它是负责用户所感知的缓慢性能.

最大的性能提升通常不是来自对算法实现的巧妙调整或优化,而是来自于认识到完全有更好的算法.一些改进相对明显,而其他改进则需要对算法进行更详细的分析,并可能对所涉及的数据结构进行重大改变.这可能包括牺牲I/O时间的处理器时间,在这种情况下,您需要确保您不仅仅优化其中一个措施.

把它带回问题,确保无论你测量什么代表用户实际体验的内容,否则你的努力可能完全浪费时间.