欢迎！请查阅关于页面了解有关如何使用本站的一些更多信息。
当构建使用 {{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}}，这可以启用缓存的字符串序列化。
这听起来合理吗？
评论者：nbeloglazov
附上建议的修复方案。分析缓存被序列化为字符串，并在 cljs.js 初始化时将其读取回 clojure 数据结构。
评论者：dnolen
请如你所建议的一样将补丁改为可选项。
你已经提交了Clojure CA了吗？
我会做的。是的，我已经提交了CA。我在那里使用了我的正式姓名，Mikita Belahlazau。
更新了补丁，增加了将核心分析缓存序列化为字符串的选项。:dump-core的有效值有:raw、string、none。为了向后兼容，旧的真/假值也被支持。
至于默认值，当前补丁使用:raw，但我想使用:string更有意义。节省最后几个mb的js空间相当不错。我认为大多数开发者不会深入探究为什么js很大，而会将其保留原样。:string引入的额外的一次性解析性能影响：当使用:string时，页面加载时间为1秒，而使用:raw时，时间约为800ms。
我怀疑这实际上是否有价值。在我看来，如果你真正关心代码大小，你只需使用Transit并在异步中加载分析？
是的，如果大小很重要，那么有更好的方式手动调整加载分析的方式。与此同时，对于本地/简单开发来说，3m比6m文件要好。唯一的缺点是速度，但我认为大幅减少大小比小小的速度损失更好。
评论者：mfikes
补丁不再适用。
