优化 cljs.core 的干燥

Question

当构建使用 {{cljs.js}} 命名空间的 cljs 源文件时，最终生成的 js 文件非常大：6.4M。如维基百科所述：[https://github.com/clojure/clojurescript/wiki/Optional-Self-hosting](https://github.com/clojure/clojurescript/wiki/Optional-Self-hosting)，它主要是由 {{cljs.core}} 命名空间的分析缓存组成的。作为解决方案，维基百科文章建议将缓存导出到单独的文件，并在运行时加载它而不是将其打包到 js 二进制文件中。我认为可以在这两者之间找到一个折中方案，这个方案不用增加用户的额外工作量，同时还能优化 js 文件的大小。这个想法是将缓存作为原始 clojure 数据结构导出而不是串行化成字符串。这样编译器就不会将缓存编译成 js（这会添加很多代码），而是留为字符串。在运行时，将使用 {{tools.reader}} 将这个字符串解析回 clojure。

以下是我的建议：[https://gist.github.com/nbeloglazov/0bf163fb62fa4b61d446](https://gist.github.com/nbeloglazov/0bf163fb62fa4b61d446)

本地检查表明，这可以将 js 文件的大小从 6.4M 减少到 2.7M，我觉得这很不错。缺点是，现在 js 在运行时必须做更多的工作（解析大字符串），而如今它只需简单地读取 js 代码并评估它。但我不认为这是一个大问题。如果需要保持所有行为，可以为 {{:dump-core}} 编译器设置添加一个新的选项，比如 {{:dump-core :string}}，它将启用缓存的字符串化序列化。

这个主意听起来合理吗？

Answer 1

评论者：nbeloglazov

附上建议的修复方案。分析缓存被串行化为字符串，并在 cljs.js 初始化时将其读回为 clojure 数据结构。

Answer 2

评论由：dnolen 提出

请按您所建议的更改补丁，使其成为可选的。

Answer 3

评论由：dnolen 提出

你提交 Clojure CA 了吗？

Answer 4

评论者：nbeloglazov

我会做的。是的，我已经提交了 CA。我在那里使用了我的正式姓名，Mikita Belahlazau。

Answer 5

评论者：nbeloglazov

更新了补丁，增加了将核心分析缓存序列化为字符串的选项。:dump-core 的可能值有：:raw，:string，:none。为向后兼容，支持旧的 true/false 值。

至于默认值，当前补丁使用 :raw，但我认为使用 :string 更合理。节约额外的几 mb 最终 js 是相当好的。我认为大多数开发者不会深入探索 js 的大小原因，而是让它保持原样。字符串引入的一次性解析性能损失是可以接受的：当使用 :string 时，页面加载时间为 1 秒，而使用 :raw 时，时间约为 800ms。

Answer 6

评论由：dnolen 提出

我在想这实际上有没有价值？在我看来，如果你对代码大小很认真，你可以只用 Transit，然后异步加载分析？

Answer 7

评论者：nbeloglazov

是的，如果大小很重要，那么有更好的方法来手动调整分析加载的方式。同时，本地/简单开发时，3m 与 6m 的文件大小差异是一个不错的进步。唯一的缺点是速度，但我认为大小的显著减小比小的速度损失更好。

Answer 8

评论者：mfikes

补丁不再适用。

Answer 9

参考： https://clojure.atlassian.net/browse/CLJS-1601（由nbeloglazov报告）