调试性能篇1

    每回上班，必会经过一条4，5公里长的马路。而这条核心马路却总不停的在修修补补，我搬到新家已经快2年了，感觉马路被大修了四次，总修理时间接近一年了。马路没有变宽，但乘客总能感到它的变化（那就是它变得更加不平)。每当经过这条路时，人们总会为盲目花费的公民税款，和机械工作的修路工人而感叹。仔细想一想，软件开发和修路还是有几分相似的。很多情况下，我们不能改变整个软件的框架，却要依据用户的建议和Bug报告，对它不停的修修补补。是吗，难道不是吗？
  最近我遇到了一个诡异（weird）的问题。一个老用户最近升级到我们的最新版本时，突然发现性能有巨大的下降（时间增加了不只10倍），于是非常愤怒，通过相应渠道提出一个紧急修改请求。用我们技术支持的话来讲，这个客户已经气的快砸天花板了。问题是性能下降发生在5年前的某个版本，而那个版本我们现在已不再支持了，当时的源码也很难被完全找到。即使找到所有源码，我如何在成千上万次找到找到性能下降的问题所在呢。要知道，性能下降又不是死锁，它没有提供足够的线索让我分析。这么看来，问题真是不简单呢。
  西方的一个谚语说：A good staff is famous by his tools。在很多情况下，最优秀的程序员也必须依靠一些工具来找到问题的所在，特别是遇到某些极端情况（如性能下降，内存或资源泄漏...）。让我看看，什么工具可以帮我平息客户的怒火，早日度过难关。
  当今原生程序(Native Code)的调优程序主要有三大产品。Compuware的TrueTime、IBM的Rational Quantity和Intel的VTune。不同Managed Code的性能调优，微软在这个领域没有什么世界级产品，这非常难得。
  如果你曾用过Softice或BoundsChecker，或者你曾读过John Robbins或Matt Pietrek的书，你一定会像我一样认为这家公司是一家伟大的公司。没有理由去怀疑Truetime的功能，只是由于它需要重新编译源码，才能进行性能调优的工作。而我们的源码非常巨大，重新编译需要非常多的时间，我想这一次它帮不了我的忙了。
  Rational Quantity也是一个很好的产品，它提供丰富的图表功能，又不需重新编译程序，非常容易使用。那不是很完美吗？问题是它在Profiling的过程中，非常不稳定，有时会Crash。不幸的事，当我运行用户的case时，它突然抛出了一个异常。
  现在，我最后的希望只能是VTune了。说起VTune,还有一个很有意思的插曲呢。但我尝试在家里AMD Duron 800Mhz的台式机安装它时，InstallShield总会跳出一个安装出错的消息，让人认为这是Intel故意对AMD机器添加的限制。当我尝试用Cracker的方式强制安装之后，它还是不能运行。突然间，我想起VTune用到了很多硬件相关的东东，它是不能运行在AMD机器之上的。当然在公司Intel的机器安装一点问题也没有，接着我尝试运行用户的case，一些竟是这样的顺利。通过对结果的分析，Hotspot来自一个简单的OLE调用（IOleObject::DoVerb)。通过追踪更改记录，我发现一个开发人员在2000年添加的这行代码。时间符合了，这句代码从表面上看没有错，问题出在哪里呢？在用户的Case中，OLE服务端是MS的Word。因为Doverb是个同步调用，一定是它的某些实现使性能出现了问题。记得很多顶级架构师都是只关心Why（为什么这样设计），而不关心How(如何设计）。一边是焦急的客户，一边是我没法接触到问题真凶Word相关的代码，这次我只能给出解决方案，但不知道Why了。
  BTW,如果你也用AMD机器，你可以去它公司主页找到类似VTune的来自AMD的一个调优工具,用法和功能比VTune弱一些，但是免费的。
 
  问题是解决了，但留给我很深的思考。难怪在某一权威机构的Survey中，程序员最需要工具列表中Profiler占据首位，Debugger才是第二位。听说过一些绝顶高手从不用Visual Studio来写C/C++程序，抑或只用VI或Notepad便玩转Java。事实上，我们可以不用IntelliSense,跳过的只是Editor而已。如果不用世界级的调试程序和调优程序，我们如何开发复杂的商业逻辑，如何在复杂的运行环境中运行呢。不要忘了，最顶级的调试大师也会为多线程问题而头痛呢。是吗，难道不是吗？^_^