4个倾向性：

前端依赖型：很少出现，这大多数都是由于CPU微指令无法及时的解析和加载造成的。但往往这意味着系统如果无法找出硬件或者微码级别的问题就无法简单的从代码出发优化程序了。

错误预测型：多半是由于系统采用的编译器和编译配置不佳，尝试从编译器方向解决问题。“换版本”也是解决方法之一。当然，对于某些应用特别是严重绑定用户行为的应用在这一块耗时较长也是可以预期的。

retire：对不起，对于黑盒应用来说无解。这已经是系统最优结果了。

后端核心依赖型：升级CPU频率，使用更多重指令优化，尽可能的提升子项中port的利用率。此外如果程序支持，只要过程中此项占比没有太大变化，采用更多的核心往往也会有非常线性的性能提升。

后端存储依赖型：根据子项中不同的cache level依赖度，找出该应用程序更多的倾向于哪个级别的cache，如果可能就找对应cache更大的产品。如果是内存的话就可以通过升级内存带宽或者更高频、更低潜伏期的内存来获得性能提升。

而top-down模型的重点在于它还可以通过一个在硬件或者软件配置的连续变化过程中倾向性占比的变化反应来预估应用程序的弹性、最大容量和最优容量。

总结下我自己对topdown分析方式的理解：topdown分析实质上是对应用程序占据的所有微指令CPU running time（CPU运行时间）的分类汇总，从这些数据进一步我们可以了解到每一个微指令基本的资源亲和力，进而为系统级别的的亲和力提供依据。