优化 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。旧的真实/假值用于向后兼容。

对于默认值，当前补丁使用 :raw，但我觉得使用 :string 更合适。保存额外的几个 MB 最终 JS 很好。我想大多数开发者不会深入了解 JS 为何体积大，就直接留下它。:string 产生的额外一次性解析性能影响是可接受的：当使用 :string 时，页面加载时间为 1 秒，而使用 :raw 时，时间是 ~800ms。

Answer 6

评论者：dnolen

我认为这实际有价值吗？在我看来，如果你对代码大小真正重视，你只需使用 Transit，然后异步加载分析？

Answer 7

评论人：nbeloglazov

是的，如果大小是关键，那么还有更好的方法来手动调整加载分析的方式。同时，当地/简单开发时，3M vs 6M 的文件大小是一个不错的胜利。唯一的缺点是速度，但我感觉减小体积比罚金小的速度更重要。

Answer 8

评论者：mfikes

补丁不再适用。

Answer 9

参考: https://clojure.atlassian.net/browse/CLJS-1601 (由nbeloglazov提交)