Common Lisp-完成非线程计算后永远100％的CPU使用率吗？

Question

更新

为了更好地说明问题，我的问题不是我是否在正确地执行代码，经过剖析后我已经了解了我不是。

问题是：无论您执行的是好是坏，您是否应该在运行程序后观察SBCL占用100％CPU？ 和，你们以前见过这种事吗？ -就是一个已知的错误？

如果可以的话，我会提供一个可复制的示例，但是这种CPU占用只是有时发生（而且我从未在任何地方使用多线程结构）。

很抱歉第一次不清楚：）

-----

臭虫？

我在运行程序后长时间使用100％CPU的Lisp偶尔遇到问题。

更新：现在程序完成计算后，它正在使用100％CPU 40分钟。

环境：SBCL，rowswell，emacs + SLIME

我的问题是，这是否是Common Lisp中一个我不知道的错误，可能与GC有关？

上下文

这不是第一次“随机地”发生，而是发生了，在程序完成之后，执行大量内存分配的更多计算密集型程序最终会长时间使用100％（在这种情况下为40分钟）。

例程是单线程的，因此不可能在后台运行某些任务。

我不认为在使用100％CPU运行程序后，SBCL花40分钟是正常的。恐怕这可能与GC中的某些错误有关？

然后我在SLIME中分析了程序：

并且该程序非常慢（执行约20分钟），做了很多分配，然后更改了一行，现在需要2秒钟才能运行，因为我总是将调试字符串格式化为空流（因此生成新的每次调用具有100k整数的列表的字符串表示形式：

（[https://github.com/AlbertoEAF/advent_of_code_2019/commit/b37797df772c12c2d409b1c3356cf5b690c8f928）

但这不是我的意思。即使这种情况非常糟糕，我正在执行的任务也非常简单，因此我正在使用的程序是无关紧要的，但关注的是平台的稳定性（在使用持续大量计算和分配。是否有关于SLIME / SBCL这样的问题或我不知道的其他问题的报告？

谢谢！

Answer 1

您的更改提高性能的原因是debug-stream为NIL。

在您评估的旧代码中：

(format nil ...)

[当您将nil作为要格式化的流时，它将打印为字符串，因此您在进行格式化工作并分配丢弃的大字符串。

在新代码中，您执行以下操作：

(when nil ...)

大约花费0。

注意nil并不意味着将其传递给format时不执行任何操作。通常，如果您不希望执行任何操作，则应该不执行任何操作，而应该调用执行该操作的函数。