Python - time.sleep(n) cpu 密集吗？ [复制]

Question

我一直在玩弄在 python 脚本中使用time.sleep(n) 以使其以不同的时间间隔执行作业的想法。伪代码如下所示：

total_jobs = [...]

next_jobs_to_run = next_closest(total_jobs)
min_time_to_wait = closestTime(nextJobsToRun)

wait until min_time_to_wait
run them all 
get next jobs

总而言之，程序会一直休眠，直到需要执行下一个作业。它运行作业，找到下一个要运行的作业，然后休眠直到需要运行下一个作业（继续到无穷大）。我计划在 linux 机器上运行它 - 使用 cron 作业是可能的。有人对这两个有意见吗？

Answer 1

不，它不是处理器密集型的。它让处理器空闲。

根据the documentation，它暂停执行，这意味着它不是处理器密集型的。 busy wait 将是处理器密集型的。

Answer 2

不，它不是 CPU 密集型的。

The documentation 说：

在给定的秒数内暂停执行。

Python 实际上并不能保证在所有可能的实现中，这意味着操作系统永远不会在睡眠期间安排您的进程。但是在每个平台上，Python 都会尝试在不使用任何 CPU 的情况下做一些适当的事情来阻塞指定的时间。在某些平台上，这可能仍然意味着一点点 CPU，但会尽可能少。

特别是，因为您询问了 linux，并且大概是 CPython：

在 linux 和大多数其他 POSIX 平台上，它通常会使用select。见the 3.3 source。

man page 清楚地表明select 会挂起，直到信号、超时或就绪 I/O（在这种情况下，没有 fds，所以后者是不可能的）。

您可以阅读内核源代码以获取完整的详细信息，但基本上，除非有任何意外信号，否则您根本不会被安排，除非select 开始时可能有少量旋转（如对select 几乎可以立即返回的情况进行了优化）。

---

在您的摘要中间，问题从“sleep CPU 密集型”变为“我应该使用 sleep 还是 cron 作业？”

无论哪种方式，您都不会在等待时消耗任何 CPU。有一些优点和缺点，但大多数都是微不足道的。从（粗略地，主观地）最重要到最不重要，一个 cron 作业：

• 允许在不编辑源代码的情况下进行配置（例如更改计划）。
• 需要配置才能工作。
• 意味着更少的代码 - 意味着更少的错误，也更少让未来的读者理解。
• 将在系统关闭后持续存在。
• 即使您的脚本因异常或信号退出，也会再次触发。
• 如果错过了 N 次（未指定，并且不同的 cron 实现做不同的事情），则可能会触发 0、1 或 N 次，而不是保证 0 次。
• 有更好的机会处理系统时钟变化。
• 每次触发时都必须为进程启动、解释器启动等付费。
• 不浪费页表和进程表空间，因为没有进程在运行，也没有内存映射。