这是一个非常宽泛的问题,因此,我认为您不应该希望任何人在这里继续为您提供有关如何衡量性能的最终正确答案。话说……
首先,您应该开发一套测试。有两种流行的技术可以做到这一点:监控应用程序完成的真实操作序列(因此,找到一些使用 AVL 或 RB 树的开源应用程序,并添加一些代码以打印出它执行的操作序列) 或以分析(或综合)的方式创建这样的操作流,以针对任意数量的情况(平均使用情况、特定类型的异常或其他异常使用情况、随机使用情况等)。您测试的此类跟踪越多越好。
一旦您有一组跟踪要测试,您需要开发一个驱动程序来进行评估。驱动程序应该很简单,对于 AVL 和 RB 树都一样(我认为在这种情况下,这应该不是问题;两者都向用户提供相同的接口,仅在内部实现细节方面有所不同)。驱动程序应该能够有效地重现跟踪集中记录的使用情况,并使跟踪操作在您的数据结构上执行。我喜欢做的一件事是加入第三个什么都不做的“虚拟”候选人;通过这种方式,我可以看到跟踪处理对整体性能的影响有多大。
每个跟踪都应该执行很多很多次。您可以将其形式化(以将统计不确定性降低到已知范围内),但经验法则是您的错误顺序将根据 1/sqrt(n) 缩小,其中 n 是试验次数。换句话说,通过将每个跟踪运行 10,000 次而不是 100 次,您将得到平均小 10 倍的错误。记录所有值;要寻找的东西是平均值、中位数、众数等。对于每次运行,尽量保持系统条件相同;没有其他程序运行等。为了帮助消除由于外部因素变化而导致的虚假结果,您可以剔除底部和顶部 10% 的异常值...
现在,只需比较数据集。也许您最关心的是跟踪所需的平均时间?也许是最糟糕的?也许你真正关心的是一致性;标准差是大还是小?您应该有足够的数据来比较在两个测试结构上执行的给定跟踪的结果;对于不同的轨迹,查看不同的数据可能更有意义(例如,如果您创建了一个对 RB 树来说应该是最坏情况的综合基准,您可能会问 RB 和 AVL 树做得有多糟糕,而您可能不会关心这个代表AVL树的最佳情况的另一个跟踪等)
CPU 时序本身就是一个挑战。您需要确保计时器的分辨率足以测量您的事件。 clock() 和 gettimeofday() 函数以及其他函数是记录事件时间的流行选择。如果您的跟踪完成太快,您可以获得几次试验的总时间(这样,如果您的计时器支持微秒计时并且您的跟踪在 10 微秒内完成,您可以测量 100 次跟踪执行而不是 1,并获取时间值10s 毫秒,应该是准确的)。
另一个潜在的缺陷是每次都提供相同的执行环境。在两次跟踪运行之间,您至少可以考虑一些技术来确保您从干净的缓存开始。要么,要么不计时第一次执行,要么明白当你消除异常值时,这个结果可能会被剔除。只重置缓存可能更安全(通过操作某个大型数组的每个元素,例如在执行跟踪之间),因为代码 A 可能会从缓存中的某些值中受益,而代码 B 可能会受到影响。
这些是您在进行自己的绩效评估时可能会考虑的一些事项。其他工具 - 例如 PAPI 和其他分析器 - 可以测量某些事件 - 缓存命中/未命中、指令等 - 与挂钟运行时间的简单比较相比,这些信息可以进行更丰富的比较。