11.0 概述
本章包含了一个例子：如何用Linux性能工具在延迟敏感的应用程序中寻找并修复性能问题。
阅读本章后，你将能够：
- 在延迟敏感的应用程序中用ltrace和oprofile弄清楚哪里产生了延迟。
- 对“热点”函数的每个调用，用gdb生成栈跟踪。
- 用性能工具确定使用了多个不同共享库的应用程序是如何消耗时间的。
- 以本章为模板，找出延迟敏感应用程序中高延迟的原因。
11.1延迟敏感的应用程序
本章我们将调查一个应用程序，该程序对长延迟敏感。延迟可以被认为是一个应用程序响应不同的外部或内部事件所花费的时间。具有延迟性能问题的应用程序一般不是长时间占用CPU,相反，它只用少量的CPU时间来响应不同的事件。但是，这种响应对特定事件来说是不够的。在修复延迟性能问题时，我们需要降低对各种时间的响应延迟，并找出是应用程序的哪些部分延缓了响应。正如你将看到的，与追踪受CPU限制的问题相比，追踪延迟问题需要的策略略有不同。
11.2 确定问题
对前一章的性能问题，我们必须定义调查内容，并尝试去克服它。本章中，我们把这个过程优化一下，使用GNOME桌面的nautilus文件管理器打开一个弹出菜单。在nautilus 文件管理器窗口的任何位置点击右键即可打开弹出菜单。在这种特定情况下，我们将调查鼠标右键点击一个打开窗口的背景时弹出菜单显示的性能，而不是鼠标右键点击一个特定文件或文件夹时弹出菜单的显示性能。
为什么要对这进行优化?即使打开一个弹出菜单的时间比一秒钟还要少，但它仍然慢到足以让用户感觉到自己点击鼠标右键与菜单显示之间的时间差。这种缓慢的弹出带给GNOME用户的印象是计算机运行的速度慢。人们注意到轻微的延迟，它会让与nautilus的交互变得烦人，或是给人留下桌面迟缓的印象。
这个特殊的性能问题与前一章中的GIMP问题不同。第一，桌面(本例中为GNOME)的核心组件通常比一个典型的桌面应用程序更为复杂与交错。这些组件为了完成工作一般要依赖于各种各样的子系统和共享库。而GIMP是一个相对独立的应用程序，这使得它更容易分析，并在必要的时候重新编译。GNOME桌面则不同，它是由多个不同的交错组件构成的。这些组件可能需要多个进程和共享库，其中每个库都代表桌面执行不同的任务。尤其是nautilus,它链接了72个不同的共享库。追踪到底是哪一段代码消耗了时间，消耗了多少，为什么消耗，可以说是一个艰巨的任务。
本章性能调查与GIMP调查第二个明显不同的地方是：我们想要减少的时间是以毫秒计，而不是以秒或分钟计。当时间小到这个程度，就很难确保捕获到的性能分析数据确实就是你设法测量的事件结果，而不只是尝试停止和启动分析工具时周围的噪声。不过，这个短暂的时间周期还是能在你感兴趣的时间内实际跟踪应用程序工作的方方面面。
11.3找到基线/设置目标
在前一个性能追踪案例中，第一步是确定问题的当前状态。为了让我们的工作更容易一点，并且回避一些上一节提到的分析问题，我们要耍点小花招，让弹出菜单问题看起来更像之前我们测量过的长时间运行的CPU密集型任务。单个弹出菜单显示的时间是毫秒级的，这使得用我们的性能工具很难进行精确的测量。如前所述，很难在合适的时间启动和停止工具，并确保我们只测量到了感兴趣的(即，打开确切菜单所花的CPU时间)。我们将在这里玩点小技巧。我们将快速连续地打开菜单100次，而不仅仅只打开一次。这样，菜单打开的总时间将会达到100倍。这使得我们能用剖析工具捕获菜单正如何执行的信息。
由于右键点击100次很乏味，且人类(除非非常训练有素)不可能可靠地重复打开一个弹出菜单100次，所以我们必须将这个过程自动化。要可靠地打开弹出菜单100次，我们依赖于xautomation包，该包可以从http://hoopajoo.net/projects/xautomation.html获得。它可以模拟一个用户，向X服务器发送任意的X Window事件。下载xautomation压缩包，解压并编译后，就可以使用它来自动执行点击鼠标右键。
与对待GIMP不同，我们不能简单地通过测量nautilus使用的CPU时间来计算创建100个弹出菜单所需的时间。这主要是因为nautilus不能在菜单被打开前立即启动，也不能打开后立即结束。我们将使用墙钟时间来查看完成这个任务需要耗时多久。这要求在进行测试时，系统没有运行任何其他的事情。
清单11.1给出了xautomation命令的shell脚本，用于在nautilus文件浏览器中打开100 个弹出菜单。运行测试时，我们必须确保面对的是nautilus窗口，这样就不会有点击实际上是打开了文件夹的弹出菜单，而是所有的弹出窗口都出现在背景上。这是非常重要的，因为不同弹出菜单的代码路径可能是完全不同的。
清单11.1中的命令把光标放置在X屏幕的(100,100)处，点击鼠标右键(按钮3)。这个操作打开一个菜单。然后它们再次右击鼠标，这次是关闭该菜单。之后移动到X位置(200,100),重复该过程。
接下来，我们用time查看完成这个100次迭代脚本花费了多少时间。这就是我们的基线时间。在我们进行优化时，我们将把优化结果与这个时间作比较看看是否有所改进。我的笔记本为普通版Fedora2的nautilus,该条件下的基准时间为26.5秒。
最后，我们要为优化选择一个目标。实现这个目的的一个简单方法是找到一个已经具备快速弹出菜单的应用程序，查看它打开100次弹出菜单消耗的时间。xterm是这方面一个很好的例子，它有非常敏捷的菜单。虽然这些菜单不像nautilus的一样复杂，但是它们至少应该被看作是菜单速度的上限。
xterm的弹出菜单操作略有不同，因此我们需要稍微修改一下创建100个弹出菜单的脚本。当xterm创建一个弹出菜单时，需要按下左控制键，因此我们必须对自动化脚本进行轻微的改动。该脚本如清单11.2所示。
