使用 clojure.core.logic 中的所有功能扩展 cljs.core.logic

Question

我在这里工作的仓库是： https://github.com/aamedina/cljs.core.logic

我基本上遵循了 clojure.core.logic 中的代码布局，并根据 ClojureScript 的需要进行了补偿，将宏移动到了姐妹 .clj 文件中。我对每个文件的宏组织的最佳方式没有坚定的意见，我所做的方式只是我发现的最简单的方式，因为这样您就不必对引用姐妹 .cljs 文件中函数的引用语法形式进行命名空间限定。

此外，我还使用 clojurescript.test 将所有 clojure.core.logic 测试移植过来。

Answer 1

评论者：adrianm

因此，我已经将仓库更新为更忠实于现有的 cljs.core.logic 代码约定和组织。我希望任何有关如何潜在优化代码以在 JVM 上运行的见解。

Answer 2

评论者：dnolen

您观察到什么类型的性能问题？您有运行特别基准测试吗？

Answer 3

评论者：adrianm

appendo 和 membero 特别慢。

(dotimes (link: i ie5) (run* (link: q) (== q true))) 的执行时间大约在 ~4500ms 左右，比 JVM 要慢约 10 倍。

通过剖析，我发现问题所在——确实需要标准的递归优化，代码在执行过程中会递归地重复行走（通过重新绑定）局部变量。例如，
对于 appendo，(run 5 (link: q) (fresh (link: x y) (appendo x y q))) 会展开成类似的一些内容...

((_0) (_0 . _1) (_0 _1 . _2) ... ))

它之所以慢，是因为每个新列表实际上都会重新遍历之前已绑定的所有局部变量。

我将在周末有更多时间来研究这个问题，但是我认为这可能是很简单的问题，只需默认不生成唯一的局部变量，因为这样，在统一检查中应该能够捕获所有的尝试。

Answer 4

评论作者：munro

我已经在使用 clojure.core.logic 和 cljs.core.logic，在 API 差异上遇到了一些困难。我认为应该停止使用 cljs.core.logic，转而使用 clojure.core.logic，因为现在有了新的读取条件。

cljs.core.logic 是否有针对 JS VM 优化的特定实现？仅仅从代码看起来，它看起来相当不同，所以这些性能问题也可能是由于没有优化算法引起的。

我可以帮助研究使 clojure.core.logic 可移植的工作，尽管我对 clojure 较为陌生。我的策略是添加读取条件，直到测试套件在 clojurescript 中通过。

Answer 5

参考资料：https://clojure.atlassian.net/browse/LOGIC-144 （由 adrianm 报告）