更新：为了回应这里和其他地方的评论，我使用SCons'GoFastButton'wiki页面上的提示完成了另一系列的SCons构建。几个月前，我看了SCons的可伸缩性，这是一个流行的基于Python的构建工具。至少可以说，结果令人失望。这篇帖子在这里和其他论坛上引起了很多评论。一些人指出，与其他构建工具进行比较会有帮助。有人认为SCons的优点是真正的增量构建，企业云服务器，而不是我用于测试的完整构建。我认为这些都是有效的，所以我决定重新讨论这个话题。这一次，我对SCons和gnumake进行了正面的比较，gnumake是构建工具的老手，我使用每种工具执行完整的、增量的和干净的构建。请继续阅读血淋淋的细节和大量图表。剧透提醒：斯科恩斯看起来还是很漂亮不好。那个与之前一样，我的测试系统是一个2.4GHz的双Intel Xeon，带有2GB RAM。但是自从上一组测试以来，我的系统已经升级到了RHEL4；有了Python的新版本；甚至还有SCons的新版本——big2.0。所以设置是现在：RedHat EnterpriseLinux 4（更新8，内核版本2.6.9-89.ELsmp）双2.4 GHz Intel Xeon，支持超线程2 GB RAMPython 2.7SCons v2.0.0.final.0.r5023GNU make 3.81与之前一样，测试构建包含一系列编译和链接：N C文件，每个文件都有一个唯一的相关头，跨N/500个目录（以确保没有文件系统可伸缩性影响）进行编译，然后绑定到标准存档库中。每20个对象都与归档文件一起链接到一个可执行文件中。构建树是使用Perl脚本生成的，它同时生成用于构建的SConstruct文件和makefile。在生成一个完整的依赖项之前，生成一个完整的依赖项，然后生成一个完整的依赖项。我觉得这与SCons进行了更实际的比较，SCons使用了详细的依赖性分析逻辑来确保精确的增量建造。圆形1： 我的兴趣主要是从零开始生成：如预期，SCons的性能相当糟糕：当我们得到一个包含数千个源文件的构建时构建时间已经超过了15分钟，并且与我们上次看到的n2增长一样，《泰晤士报》经过了一个小时，然后是两个小时，最终对于一个只包含50000个源代码的构建来说达到了将近5个小时文件.GNUmake显示了一个更加稳重的线性增长——事实上，它与一个简单的shell脚本保持了同步，这个脚本可以执行所有相同的编译和链接作为常规构建，但没有构建工具的任何开销。是的，我知道shell脚本不能代替正确的构建工具。它只是给我们一个概念，让我们知道在构建中完成工作需要多长时间，这是构建时间的下限。没有一个构建工具可以以比这个更快的速度运行构建（很明显，如果我们使用并行构建特性，我们可以通过一个常数因子）来计算构建工具引入的开销。除了实际运行执行构建所需的命令之外，该工具所花费的所有时间都在执行：解析SConstruct文件或makefile、构建依赖关系图、遍历该图、计算命令行等。将此开销视为总构建时间的百分比，可以使我们更容易地进行比较在斯科恩斯和GMake：即使有相对较少的文件（大约2000个），超过50%的总构建时间被scon的开销所浪费。相比之下，GMake在这么大的版本上几乎没有任何开销。在这个范围的另一端，SCons开销占整个构建时间的近90%。GMake的开销占总时间的百分比也有所增加，但只增加到20%左右，仍然明显低于SCons。事实上，对于50000个文件，GMake的开销不到SCons开销的一半，而SCons只有2000个文件！好吧，在我们讨论增量构建时间之前，这里还有几个问题需要讨论：首先，您可能注意到了SCons完整构建时间（45000到50000个文件）的突然钩住。这意味着，在我的系统中，在这个层面上，还有一些其他因素影响了《时代》。我相信这是因为系统已经开始大量分页，大数据查询，因为SCons的内存占用已经增长到消耗所有可用的RAM。其次，如果将本文中的SCons时间与上一篇文章中的SCons时间进行比较，您会发现这一次SCons的时间比上一次好一点——平均大约30次。请记住，此设置与以前的设置有几个不同之处：新的操作系统、新版本的Python、新版本的SCons。甚至是编译程序的新版本和构建过程中使用的其他工具。我确实通过测试Python和SCons的各种版本组合（例如，python2.6.2和scons2.0；python2.7和scons1.2.0）来确定哪些因素促成了这种改进；这些测试都没有在性能上产生任何显著的变化，因此，我认为性能差异很可能是由于新的操作系统和工具。我决定不再追究此事那个。圆的2： 增量构建很多人声称完整的构建"其实并不重要；开发人员只做增量构建"。让我们看看增量构建pe性能：为这些构建，我运行了一个完整的构建，然后修补了一个C文件及其相关的头文件。这导致了一个对象文件的重建，然后是对该对象馈送到的归档文件和可执行文件的重建。仅仅执行这些命令的实际时间只有十分之一秒，因此对于任何一种工具，增量时间都由工具本身增加的开销控制。即便如此，显然SCons比GMake增加了更多的开销。即使是一个只包含2000个文件的小版本，SCons也要花费35秒来完成十分之一秒的工作。GMake在3秒钟内完成了同样的构建。对于50000个文件的构建，SCons运行了大约25分钟，同样是为了完成十分之一秒的实际工作；GMake运行了大约9分钟几分钟。一分钟关于这个图，我发现特别有趣的一点是，完整构建的问题是，它们迫使scon不断地重新扫描依赖关系图。在增量构建中，这应该是不必要的，但是我们仍然可以看到构建中的O（n2）增长时间。回合3： 清理构建上一个构建比较是一个干净的构建：scons-c与gmake Clean：最后我们发现了一个构建变体，scons的性能与gmake是一样的！当然，大数据需要学什么，根据SCons文档，您永远不需要使用SCons进行干净的构建（因为使用SCons，您的依赖关系非常精确），所以可能这个数据点实际上对SCons并不感兴趣用户。突然死亡超时：内存使用上次比较：内存使用。这个度量特别有趣，因为它对工具可以处理的最大生成大小设置了硬限制。我已经学会了提高内存效率的重要性——在"救火"模式下长夜工作，以提高内存使用率，以适应这个或那个客户的巨大体型。我希望在这个测试中使用的Python和SCons的新版本能够证明对SCons内存占用是有益的。不幸的是，情况恰恰相反：现在的内存使用率比我上次运行这些测试时要差8倍，正如您在这里看到的，SCons使用的内存是上次运行这些测试时的4.5倍GMake：50分，淘客如何推广，0000个文件，SCons只使用了不到2GB的内存，足以让我的测试系统（有2GB的RAM）开始交换。相比之下，GMake只需要440MB内存来存储50000个文件。按照这个速度，GMake在构建到超过22.5万个文件之前不会开始攻击我的系统。不幸的是，SCons开发人员似乎没有太多办法来解决这个问题：因为SCons是用Python实现的，信息大数据，所以它们受Python运行时实现的支配。当您使用解释的语言。结论现在可以清楚地看到，不是简单的"野兽的本性"让斯科恩斯的表现如此糟糕。GMake在各种场景下的扩展要优雅得多，包括运行时间和内存使用情况：完整的、一键式增量的和干净的构建。从上一篇文章引发的讨论中，我们知道主要问题是SCons实现中的一个效率低下的O（n2）算法。看起来，SCons在学术上很有趣，但最终对任何不重要的构建都不实用（因为我的一些客户现在发现了困难的方法），SCons的开发人员做出了一个谨慎的决定，将重点放在正确性而不是性能上，"但是一个正确的系统如此缓慢以至于无法使用，这有什么好处呢？如果构建花费的时间太长，如何持续交付。为什么首先要在速度和正确性之间做出选择呢。对我来说，选择是一个无需考虑的问题：我的时间太宝贵了，不能浪费在一个缓慢的构建工具上。