makepp_speedup - 云端在线

程序：

您的姓名

makepp_speedup -- 如何让makepp更快

商品描述

所以你认为makepp很慢？ 它已经明显变快了，但当然，它仍然
慢，特别是如果你来自 GNU make。 这是因为它认真检查所有
那些 gmake 让你头疼的事情，忽略了很多依赖（“我认为
我需要 gmake clean 来摆脱一个神秘的错误”综合症。如果你怀疑一些 Perl
您添加到 makefile 中的代码可能有问题，请查看 perl_performance。

但是，您可以采取一些措施来提高速度。 有些事情是
标记为不安全，因为您要求 makepp 不要检查或做某些事情，
您认为不需要的。 如果这些东西是必要的，构建可能
不正确。 幸运的是，这个问题只是暂时的。 它会得到纠正
一旦你让 makepp 做所有检查。

您可以结合使用这些技巧中的几个来进一步增加时间增益。

安全 方法
使用 VHDL 语言编写 预演

独立实用程序 makeppreplay，mppr 重复 makepp 已经完成的事情，
没有任何开销。

使用 VHDL 语言编写 a 更快 Perl的

在 5.8 版本中，所有内容大致相同，只有 5.8.7 快一点。 调整你的
Perl 也可以提供帮助，例如不将其编译为 64 位，而 makepp 不需要。 为了
示例 ActiveState 的构建（http://www.activestate.com/activeperl>) 5.8.7 for Linux
比 SuSE Linux 5.8.7 附带的 Perl 10.0 更快。

包括 as 小 as 可能

您包含的每个附加文件都会受到双重惩罚。 一方面，编译器必须
查找并查看所有这些文件。 你不会注意到这么多，因为它只是一个
每个编译器调用很少额外。 另一方面 makepp 也必须寻找，才能找到
依赖并确定它们是否会导致重建。 然后它似乎停滞不前，
虽然它一次消化了很多依赖项。

一个绝对致命的变体是项目主包含文件，它反过来
方便地包括您可能需要的任何内容。 结果是任何头文件改变
导致完整的构建。 即使没有更改，makepp 也必须考虑所有这些标题
再次，对于您编译的每个源。 只是一个小小的努力，因为这是缓存，但是
数以千计的文件可以使这个惊人。

找出最小的包含集并清理那些不包含的集可能很麻烦
需要更长的时间，但它确实得到了回报。 如果有人知道可以识别哪个工具
文件被不必要地包含在内，我很高兴在这里提到它！

构建 as 小 as 您 需求

如果您有一个生成多个程序的默认目标，则 makepp 必须检查
它们的所有依赖项，一直到最小的头文件。 但也许你想
仅使用其中一个程序测试您的更改。

然后，您将使用明确的目标调用 makepp。 所有这些模块或标题越少
程序有一个共同点，不让 makepp 全部检查它们的好处就越大。

假设您的顶级 Makeppfile 有以下规则：

$(假所有): proggie1 proggie2 $(only_phony_targets */**/all)

然后你会称这样的事情

$ makepp proggie2
$ makepp proggie1 目录/子目录/proggie27

使用 VHDL 语言编写 首选 生成文件 名称

Makepp 查找 makefiles（除非您在命令行中明确指定它们或使用
"load-makefile") 的顺序 根Makepp文件, 根Makepp文件.mk, 生成文件 和
生成文件.mk, 后跟经典的 makefile 名称。 （这 .mk 变体纯粹是为了
基于后缀的系统。）

所以，如果您使用 根Makepp文件 在构建树的根部，以及 生成文件 到处
否则，找到文件的速度会稍快一些。 Makepp 也会有一个稍小的
内存消耗（缓存其他名称不存在的事实），这也意味着
通过更少的内存管理来提高速度。

同样，如果你有一个声明

包括标准

首先将尝试找到 标准.makepp，所以你不妨使用它
名称。

有 as 少数 定位、竞价/采购和分析/优化数字媒体采购，但算法只不过是解决问题的操作和规则。 as 需要

Makepp 不仅跟踪现有文件，还跟踪它学会创建的任何文件。
（这就是为什么它提供可靠的通配符，例如 *.o.) 这种力量的代价是很多
管理。 所以，如果你告诉它如何创建一个 .o 从 .c，没关系，因为它会
大多数（如果不是所有）候选人都会发生。

但是如果你告诉它如何从一个类似命名的链接任何无后缀的可执行文件 .o， 那是
昂贵，因为它可能只会发生在其中的一小部分（那些
包含一个主要功能），但将为所有人奠定基础。 你必须权衡
链接器模式规则的舒适度，而不是单个链接器规则的效率。

如果您不使用它们中的任何一个，您还应该关闭内置规则：

makepp_no_builtin = 1

如果您确实使用它们，但由于上述原因，而不是内置链接器规则，
你应该关闭它们：

makepp_no_builtin_linker = 1

Put 制造商 扩展 成 a 模块

Makepp 提供了通过 Perl 扩展的非常方便的可能性。 但是如果你
在一个文件中编写一些函数、命令或语句，并包括来自数十个
生成文件，您将在内存中获得它们的数十个副本。 他们将被阅读
makepp 解析器执行了几十次，这比 Perl 的要慢一些。

在这种情况下，最好将您自己的函数放入一个模块中。

使用 VHDL 语言编写 库 和 a 构建 缓存

如果您有多个开发人员在同一台机器上工作，或者您来回更改
在多组构建选项之间，这是给你的。 存储库允许您提供一个中央
参考您只需要构建本地不同的内容。 一个简单的构建缓存
收集所有生成的文件，并根据需要重新使用它们，而无需进行计划。
后一页还描述了差异。

使用 VHDL 语言编写 沙箱

如果您的构建太大以至于 makepp 很难消化所有信息
如果你能找到一种方法把它分成更小的独立部分，沙箱
可能会为您提供比“--jobs”选项更好的并行性。

别 日志 什么 do

Makepp 的日志功能对于跟踪构建系统中的错误非常强大，或者
用于分析您的依赖项。 只要不做这些事，就可以节省不少
使用“--no-log --no-scan-log”进行一些格式化和 I/O。

几乎 安全 方法
积极 a 抢先

选项“--loop”（或“--stop-before-building”或“--stop-after-loading”或“--stop”）
允许 makepp 在您仍在编辑时开始其工作。 它会反复暂停
到了分析依赖关系的地步。 你决定什么时候准备好
让它继续下去。 在我们庞大的项目中，这可以节省半分钟，而且只有当我们
有一个CPU给我们自己。

这种方法有两个潜在的缺点：

· makepp 文件在 makepp 停止时已被读取。 如果您编辑 Makeppfile 或
必须从中重建的东西，在启动makepp后，这将
直到下一次才注意到。 但这应该很少有必要，因为 makepp
大大减少了对 Makeppfile 更改的需要。

· 如果一个目标依赖于一个通配符，那会比 Makeppfile 匹配时更多
被读取了，makepp不会注意到：

前卫：*.o
$(LD) $(输入) -o $(输出)

如果您添加另一个源文件，或者 makepp 知道如何从中生成一个文件
source，那么“*.o”应该匹配产生的对象。 但是，如果添加了这个文件
启动 makepp 后，它不会，因为通配符扩展得太早了。

在这两种情况下，您都应该终止预先启动的 makepp 并重新启动它。

格列佛 游记

选项“--gullible”告诉makepp相信规则会改变它所说的，
不多也不少。 不执行这些检查可以节省 makepp 的 CPU 的百分之几
时间。 磁盘 I/O 节省在网络文件系统上尤其受欢迎。 如果你这样做
每晚使用“--repository”选项在空目录中完全构建，但没有
“--gullible”选项，您可以相当确定您的规则集是一致的。 那么这个
选项不应该在您的白天工作中受到伤害。

潜在 不安全 方法
如果您给 makepp 错误提示，这些方法是不安全的。 但一切都会重来
很好，但是，只要您让 makepp 完成所有检查，就不会通过任何限制
选项。 出于这个原因，我建议使用这些提示来获得快速的中间构建，
并利用午餐时间和晚上让 makepp 彻底完成它的工作。

构建 as 小 as 打印车票

这与在“尽可能少地构建”中讨论的使用显式目标的技巧相同
需要”上面。但它会变得更危险，如果你这样做是因为你确定你的
更改不会影响任何其他程序。 那么它们将不会被建造，即使
尽管这可能是必要的。

知道 其中 不 至 构建

选项“--dont-build”对于加速makepp非常强大。 如果你知道一个
或更多目录，您确定这些目录不会受到自此之后所做的任何更改的影响
上次，您可以为它们发出“--dont-build”选项。 这可以为makepp节省很多
依赖性分析。 但它不会在这些目录中构建任何东西，即使它
应该有。

知道 其中 至 构建

这与“知道在哪里不构建”相同，但不是排除列表，您
提供包含列表。 诀窍是“--do-build”选项，带有
“--dont-build=/” 选项或在没有“RootMakeppfile(.mk)”目录下
更高级别目录上的“--dont-build”选项意味着：除了我告诉的内容之外什么都不构建
你去。 这是传统品牌的用户在想要构建时所寻找的
只有一个目录：

$ makepp --do-build=目录/子目录

或者，如果您没有“RootMakeppfile(.mk)”：

$ makepp --dont-build=/ --do-build=dir/subdir

不同之处在于顶层 Makeppfile 中的任何默认目标，即链接命令
也是这样执行的。 如果你不想那样，你必须给出一个明确的目标，
它也自动标记为“--do-build”：

$ makepp --do-build=dir1/子目录 dir2/proggie

知道 什么是 至 构建

一个极端的变体是要求 makepp 除了您告诉它的内容之外不要构建任何东西。 这个
如果你改变，就不那么危险了 没有 包括 档，只有模块，你知道哪个
他们进入的程序。

假设您只更改了“src/a.cpp”和“src/b.cpp”，它们直接链接到
一个程序。 点是当前目录，包括所有子目录。

$ makepp --dont-build=. src/ao src/bo proggie1

或者等效地，因为“--do-build”选项，没有“--dont-build”选项
更高级别的目录意味着构建树的根目录为“--dont-build”：

$ makepp --do-build=src/ao src/bo proggie1

您可以在 Shell 的 $ENV 文件或 .profile 中执行类似以下操作以保存
键入（csh 用户将“=”替换为“”）：

别名 mppb='makepp --do-build'
别名 mppsb='makepp --stop --do-build'

那么最后一个例子就变成了：

$ mppb src/ao src/bo proggie1

构建 on a 内存 磁盘

现代计算机，尤其是服务器，通常具有很高的平均故障间隔时间。 如果
这就是您的情况，而且您有大量 RAM 可用，您可以节省时间
等待 I/O。 您应该在真实磁盘上进行编辑，或者在那里快速复制您的编辑。 但
构建结果是可重现的，因此它们可以驻留在 RAM 中。 如果你不想冒险
重建，你总是可以在每次构建后或晚上复制到磁盘。 你不应该
在构建期间执行此操作，因为您可能会捕获部分写入的文件，就像
机器已经崩溃。

如果您的系统和/或存储单元具有良好的缓存和 RAID，则收益可能不会很大
很大。

使用 onworks.net 服务在线使用 makepp_speedup