优化 cljs.core 输出

Question

当构建使用 {{cljs.js}} 命名的空间作为 cljs 源代码时，最终的 js 文件会变得非常大：6.4M。如维基百科所述：https://github.com/clojure/clojurescript/wiki/Optional-Self-hosting，它主要是由 {{cljs.core}} 命名的空间的分析缓存构成的。作为一个解决方案，维基百科文章建议将缓存转储到单独的文件，并在运行时加载它，而不是将其捆绑到 js 二进制文件中。我认为可以在两者之间有所作为，这样就不需要用户额外付出努力，同时还能优化 js 文件的大小。这个想法是把缓存不是以原始 clojure 数据结构的形式转储，而是序列化为字符串。这样编译器就不会将缓存编译成 js（这会增加大量的代码），而只是让它成为一个字符串。在运行时，这个字符串将被解析回 clojure 使用 {{tools.reader}}。

以下是提议：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 报告）