很多时候我们需要justify自研一个渲染器的合理性，最重要的一个说辞是自研“可以做到”顶尖的性能优势。我们日常会做测试写报告来证明我们实现了具体什么优势，来说服自己的工作是有价值的。但是近年实际的工作中，关于这些种种，总是有些想法。
两个渲染器在渲染性能上实现的侧重点不同。相同的workload，对于侧重点不同的实现来说可能有明显的表现差异。这样的实现侧重点可能是因为平台限制导致，业可能是因为环境配置导致。显然的，客观合理的对比渲染器性能，需要准备相同的workload，使用相同的平台和环境。
这么做真的客观吗？这么做的客观性来自于结论上的定语是否存在，「在某workload，在某平台上」渲染器A相比B具有百分之X的性能优势。如果这个定语缺失，那么这个结论就是错误的。因为渲染器对比的客观性总是建立在这样ctx，所以任何声称的渲染器性能优势的广告，如果没有明确这样的ctx，那么就是没有任何价值的「宣传」
选取特殊的ctx，或者对benchmark的ctx，做特殊的优化，在性能评估上可以轻易的获取正面的结果。所以是否能客观且「整体的」对比两个渲染器的性能表现，取决于ctx是否能客观且整体的选取。而这一点是困难的。
客观且整体的选取有两个目标，这取决于「客观和整体」如何定义。一种是脱离业务场景的，从全面性的角度广泛的选取代表性的ctx。一种是聚焦于业务场景，完全从业务场景出发来确定ctx。我认为这两个方向在技术的角度都有价值，当然从产品的角度肯定是以后者入手容易。
全面性的选取ctx本身就是困难的，这取决于所有人对全面性的理解，整个领域内哪些case重要哪些case不重要？业务场景出发的ctx提取的困难之处在于准确性和建设成本，workload的角度，真实数据的录制和还原是必需的，target/platform的角度，必要的统计也是必需的。业务领域的覆盖率也是问题，评价的权重也是问题。
即便测试方法和措辞是严谨的，性能报告可能会引导出misleading的决策。对于一个不了解问题的人，看到和写下没有触及问题的结论是没有意义的。这样的对比往往草率，目的性强，然而无益于将事情做好。
假设我们有AB两个渲染器，以我们产品的ctx来对比性能，A显著好于B，选择A就是正确的理由吗？即便从性能的角度出发，我认为也不能得出为了更好的性能选择A优于B的结论。
假设A相对B这样的性能优势有30%，但是如果产品层面作出一些简单的策略调整，比如兼容性的考量，或者改变api的使用方式，甚至修复一些不合理的做法，使得ctx本身以较低的成本发生了变化，进一步使得B进入了性能的优势区域，性能优势反而超过A 100%。这种情况下选择A显然是不合理的。这种情况其实并不少见，因为A的优化目标很可能是局部最优的，A能做的相对好，可能只是因为其投入了很多努力，去优化本来就不合理的ctx下的性能表现。合理的做法是我们从整体的角度来判断ctx变化下，多种选择的技术潜力
A相对B建立这样的性能优势，在技术实现上有可能是做了特别的取舍的，这样的取舍，是可能对后续产品层面的进一步发展起到制约作用。比如后续某个重要功能会很难做甚至无法做，比如后续的维护成本很高。那么显然选择A就是错误的，而这必须有赖于决策者能够理解性能差别的原因。
B相对A，没有表现出这样的性能优势，有可能只是简单的没有做相关的技术建设，有可能在B之上去重新实现A的优化，成本远低于A，实现质量远高于A。A现在的性能表现优势会很重要吗。
是否能够reason性能差异现象的原因，而不是被数据简单左右，是做理性决策的基本要求。一份性能报告呈现上来，能提供一些决策依据，但具体如何解读，取决于技术负责人的基本素质。一个成熟的项目，在其起步，演化的过程中，肯定是需要，肯定是已经对同类方案做对比研究的，第三方的报告提供者不一定有资格有实力提供真正有价值的信息。而第一方的报告提供者，作出的报告，多数具有准备review材料或者marketing的性质，其重要性或许也不会太高。
在若干年前我一向幼稚的认为性能就是王道。然而现在我不这么看了。渲染性能往往不是最重要的，甚至往往不是重要的。
这样的想法一方面来自于对优化方向的不了解。神秘的，美好的事情，容易变成浪漫的追求。如果性能上的大部分做法，原理取舍，物理上限，都了解过了，那么有时甚至会觉得这个事情的乐趣只剩下工程上的挑战。A和B的性能差别，可能只是取舍，或者是少做一块，或者是错做一块，代码看看一目了然。A要是哪里做的好，甚至可以盲猜一二，大概率是做了什么什么，要在B里做类似的，需要做什么什么，要做多久。奇技淫巧什么几乎不存在的，有的只是一个个feature point，一个个具体原理，和要注意的海量的实现细节。
这样的想法另一方面来自于缺少工程实践。堆功能赶进度，当水管工糊胶水，定位排查问题，才是实际工作的主要内容。大部分小细节的性能的关注点在实现上会变成一个个placeholder，属于那种不重要不紧急的东西。而性能中心的feature从一开始就把性能目标作为feature来做，只要做了就是大局已定的状态。无论是继续强化，还是放任不管，工程上都心安理得。总之实际上，追求绝对性能，不会总是处于高优先级地位，甚至不常处于高优先级。
技术上长期来看，渲染性能往往不是最重要的，重要的是正确的和远见的工程框架建设，好让我（以及一群开发者）有条不紊的把feature和性能优化都干净的一个个填充和扩展进去，让上述的AB反例总是清楚的展现出来，以及重要的，让我能轻松的根据场景来定制feature的行为和存在。相比某个ctx下渲染性能几何，做feature和优化的难易程度，维护难度，调试体验，质量，我认为更加重要。一个局部做的足够好，但是miss了big picture，以至于难以长期做正确的事情的codebase，我认为是价值有限的。
产品层面上看，性能在某些情况下可能处于不值得一提的状态。即便是重图形的编辑器应用，如果你的产品投入很多成本，魔法般的保持性能上对竞品20%的可感知优势，但是基本的交互使用逻辑很不合理，或是功能丰富程度大幅不及，很难说这样的投入是合理的。
大家都实际上了解如何做优化，其中不具备实际的技术壁垒。如果连基本的做法都不了解，那么一开始就不会出现在牌桌上，活着也会很快被淘汰。性能这种基础建设投入，很大程度上，只是避免犯错，只是即使的根据时代的发展（比如新的api，硬件的普及），及时的把该做的事情做出来即可，总是工程上的竞争大于研究上的竞争。