datetime.datetime.now 在多处理中的性能答案

【问题标题】：Performance of datetime.datetime.now in multiprocessingdatetime.datetime.now 在多处理中的性能
【发布时间】：2015-10-19 11:13:15
【问题描述】：

在使用 python 多处理编写一些并行代码时，我注意到在我的 Mac 笔记本电脑和 Windows 服务器机器上运行代码之间存在奇怪的性能行为差异。当我串行运行代码时，Mac 笔记本电脑的速度大约是 windows 机器的两倍，但在运行 2 个核心时速度是 windows 机器的两倍，并且它的性能随着核心数量的增加而趋于稳定（仍低于总核心数），而 windows 机器显示出不错的缩放比例。

查看 cProfile，我意识到使用多个内核时，Mac 几乎所有时间都在调用 datetime.datetime.now，它用于执行一些内部计时，使用以下上下文管理器：

class timer:
    def __init__(self):
        self.timer = datetime.datetime.now

    def __enter__(self):
        self.start = self.timer()
        return self

    def __exit__(self, *arg):
        self.end = self.timer()
        self.elapsed = (self.end - self.start)

使用类似：

with timer() as t:
    <run some code>
total_time += t.elapsed

当我修改代码以不调用datetime.datetime.now 并设置self.elapsed = datetime.timedelta(0) 时，我恢复了正确的并行缩放。

我在 Windows 下看不到这种行为，所以我想知道为什么 OSX 会从多个进程调用 now() 时受到性能影响。与单个串行运行相比，调用程序的两个串行实例不会导致一个进程影响另一个进程的性能。

有人对这种行为有解释吗？我在两台机器上都使用 Python 2.7.10。

【问题讨论】：

当您检查时间时，听起来好像 OS X 正在采取某种系统范围的锁定。不过，我不明白为什么这应该是必要的。也许它需要自动复制系统时间之类的？

标签： python multiprocessing

【解决方案1】：

This question 可能会给出解释。

我的猜测是 MAC OS 不允许对实时时钟进行并发读取访问。因此，当时只有一个进程可以读取该值，从而大大降低了性能。

要验证上述链接中给出的答案，您可能会检查进程在读取时间时是否实际上因 IO 等待而暂停。只需生成大量只读取时间的进程并检查它们是否在 IO 等待中暂停。

【讨论】：