Python-time.sleep(n)cpu是否密集? [英] Python - is time.sleep(n) cpu intensive?

问题描述

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

I've been toying with the idea of using time.sleep(n) in a python script to make it execute jobs at different intervals. The pseudocode would look like:

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作业是可能的.有人对此有意见吗?

To summarize, the program sleeps until the next job needs to be performed. It runs the job, finds its next job to run, and sleeps until it needs to run the next job (continues to infinity). I am planning on running this on a linux machine - using a cron job is a possibility. Anyone have opinions on either?

推荐答案

不，它不占用CPU.

文档说:

在指定的秒数内暂停执行.

Suspend execution for the given number of seconds.

Python不能真正保证在每种可能的实现中，这意味着OS永远不会在睡眠期间安排您的进程.但是在每个平台上，Python都会尝试在指定的时间内执行适当的操作以在不使用任何CPU的情况下进行阻塞.在某些平台上，这可能仍意味着需要一点CPU，但是它将在合理范围内尽可能减少.

Python can't actually guarantee that in every possible implementation, this means the OS will never schedule your process during a sleep. But on each platform, Python tries to do something appropriate to block for the specified time without using any CPU. On some platforms, that may still mean a little bit of CPU, but it's going to be as little as reasonably possible.

特别是，因为您询问了有关linux以及大概是CPython的信息:

In particular, since you asked about linux, and presumably CPython:

在linux和大多数其他POSIX平台上，它将通常使用select.参见 3.3源代码.

On linux, and most other POSIX platforms, it will generally use select. See the 3.3 source.

手册页使select暂停直到信号，超时或就绪的I/O(在这种情况下，没有fds，因此后者是不可能的.)

The man page makes it pretty clear that select suspends until signal, timeout, or ready I/O (and in this case, there are no fds, so the latter is impossible).

您可以阅读内核源代码以获取全部详细信息，但是基本上，除非有任何意外的信号，否则根本不会安排您的计划，除非在select的一开始可能进行少量旋转(如对select几乎可以立即返回的情况进行了优化).

You can read the kernel source for full details, but basically, unless there are any unexpected signals, you won't be scheduled at all, except possibly a tiny amount of spinning at the very start of the select (as an optimization for the cases where select can return almost immediately).

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

In the middle of your summary, the question changes from "is sleep CPU-intensive" to "should I use sleep, or a cron job?"

无论哪种方式，您都不会在等待时燃烧任何CPU.有一些优点和缺点，但大多数都是琐碎的.从(大致上和主观上)最重要到最不重要的是，cron工作:

Either way, you're not burning any CPU while waiting around. There are some pros and cons, but most of them are trivial. From (roughly, and subjectively) most important to least, a cron job:

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

• allows configuration—e.g., changing the schedule—without editing source code.
• requires configuration to work.
• means less code—meaning fewer bugs, and less for any future readers to understand.
• will persist across system shutdown.
• will fire again even if your script exits with an exception or a signal.
• may fire either 0, 1 or N times if its scheduled interval is missed N times (this isn't specified, and different cron implementations do different things), instead of guaranteed 0.
• has a better chance of handling system clock changes.
• has to pay for process launch, interpreter startup, etc. each time it fires.
• doesn't waste page table and process table space, because there is no process running and no memory mapped.

这篇关于Python-time.sleep(n)cpu是否密集?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！