通过跳过没有源代码变化的模块的重新编译/再生成来提高CLJS模块构建时间

Question

我正在尝试改进一个用例的自动构建时间，在这个用例中我们不能使用 } (这是一个 Chrome 扩展程序，Chrome 的安全策略禁止动态加载 JS，对于注入网页的情况)。因此，当我使用下一个最快的优化选项 } 时，它花费了大量时间 (~30sec 对于即使是微小的更改)，因为应用拉入了大量依赖项。我尝试使用新发布的模块功能将输出拆分为两个文件，一个包含所有依赖项，另一个包含我的代码，并观察到 ClojureScript 编译器不会跳过为源文件根本未更改的模块进行再生成。

深入研究代码，它看起来是closure.clj中的{{optimize-modules}}函数中的函数的一次微调变化，我们可以在其中跳过跳过所有源文件都未发生变化的模块的生成。

Answer 1

评论者：dvdreddy

您好，
我不确定社区关于问题方面的最佳实践，因此创建了一个JIRA，如果您想在(clojurescript)谷歌组中进行初步讨论（链接： https://groups.google.com/forum/#!forum/clojurescript），我将将其移动到谷歌组。

谢谢

Answer 2

评论者：thheller

通过Closure Compiler处理的模块仅当整个程序使用时才有效。不可能输入部分代码并重用另一轮编译的文件。否则，编译器将注入冲突的goog/base.js以及可能的其他元素。

然而，不使用Closure Compiler组合输出是很容易的。只需将给定模块的所有来源源代码连接到单个文件中，无需任何处理。遗憾的是，CLJS没有提供方便的钩子来执行此操作。

Answer 3

评论者：dvdreddy

(链接：~thheller) 我同意，我观察到的是从文件生成的时间戳来看，Closure Compiler并不是耗时的步骤，而是生成源映射，如果我们禁用源映射，可以将其时间缩短到约5秒（开发过程中不能没有它们），并观察到在生成js文件后，cljs-base模块的js.map文件的生成占用了整个30秒编译时间中的超过15秒。正是这部分我想看看我们是否能跳过。

Answer 4

评论者：dvdreddy

(链接：~thheller) 对上面的内容有什么评论吗？

Answer 5

评论者：thheller

源映射不应该占用这么多的时间。你使用的硬件/操作系统是什么？你难道是写在一个网络挂载的驱动器上吗？源映射可以非常大，因此I/O可能很慢。

Answer 6

评论者：dvdreddy

这是一台普通的2013 Macbook pro，没有涉及NAS。生成的源映射大小约为6MB，对于固态硬盘来说不算太大，让我看看能否分析一次构建过程，并给你提供更具体的瓶颈信息。

Answer 7

参考：https://clojure.atlassian.net/browse/CLJS-2481 (由alex+import报告)