优化 cljs.core 打印

Question

当构建使用 {{cljs.js}} 命名空间的 cljs 源代码时，最终的 js 文件相当大：6.4M。如维基百科所述：https://github.com/clojure/clojurescript/wiki/Optional-Self-hosting，它主要包含 {{cljs.core}} 命名空间的分析缓存。作为一个工作区，维基百科文章建议将缓存打印到单独的文件，并运行时加载，而不是将其打包到 js 二进制文件中。我认为有一个解决方案，它既不需要用户额外努力，又能优化 js 文件的大小。这个想法是将缓存序列化为字符串而不是原始的 clojure 数据结构，这样编译器就不会将缓存编译成 js（这会增加很多代码），而是保留字符串。在运行时，此字符串将使用 {{tools.reader}} 解析回 clojure。

以下是建议：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引入的额外一次性解析性能损失是可以接受的：当使用:string时，页面加载时间为1秒，而使用:raw时，时间大约为800ms。

Answer 6

评论者：dnolen

我怀疑这是否真正有价值。在我看来，如果你真的重视代码大小，你只会使用Transit并异步加载分析？

Answer 7

评论者：nbeloglazov

是的，如果大小是关键，那么还有更好的方法手动调整加载分析的方式。同时，对于本地/简单开发来说，3MB文件比6MB文件更好。唯一的缺点是速度，但我认为大幅减少的大小比小小的速度损失更有优势。

Answer 8

评论由：mfikes发表

补丁不再适用。

Answer 9

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