代码之家 › 专栏 › 技术社区 › RoadRunner

subprocess.Popen在WSL Linux上花费的时间太长

windows-subsystem-for-linux subprocess python

RoadRunner · 技术社区 · 7 年前

我有这个 subprocess.Popen()

with Popen(
    args=command, shell=False, stdout=PIPE, bufsize=1, universal_newlines=True
) as process:

    # TIMING
    start = timer()
    lines = list(process.stdout)
    end = timer()
    print('Time taken:', end - start) # 53.662078000000065 seconds -> Linux

    for _ in tqdm(iterable=lines, total=len(lines)):
        sleep(0.1)

if process.returncode != 0:
    raise CalledProcessError(returncode=process.returncode, cmd=process.args)

这似乎需要53秒来处理 list(process.stdout) 在WSL Linux环境中运行时。但是,当我在Windows环境中运行它时,只需要0.6秒。我觉得奇怪,为什么时间如此不同。

我试过使用 subprocess.run() 和 subprocess.check_output() tqdm() 环

我是不是遗漏了什么?我试着查看文档,看看它们之间有什么区别 subprocess.Popen() 在Windows vs WSL Linux环境中,但我仍然不确定问题出在哪里。也许 列表(process.stdout) 在这里是不必要的,并且有一种更好的方法来存储来自stdout的行。

在这里,任何形式的指导都会非常有用。

1 回复 | 直到 7 年前

wizzwizz4 7 年前

Linux的Windows子系统有点垃圾。它有很多很多bug,而且速度比需要的慢得多。这只是另一个正在显现的bug。以下是一些可能的瓶颈:

WSL没有注意到等待管道的整个进程意味着管道的另一端现在应该运行。
正在延迟执行的子进程。
wsl.exe 启动该计划(感谢RoadRunner!)
Windows通常的开销,加上Linux通常(相对较小)的开销。
systemd (?)
由于未知原因,Windows决定在子进程之前运行其他内容。
~~Windows子系统故意恶意攻击Linux开发人员,通过设置一个strawman来“证明”Windows是优越的操作系统。~~ 太傻了。

VonC 6 年前

您需要在2019年第三季度与WSL2一起重新评估该性能问题。

见“ Announcing WSL 2 “从 Craig Loewen

文件密集型操作,如 git clone , npm install , apt update , apt upgrade ,而且更多的速度都会明显加快。

在我们运行的初始测试中,与WSL1相比,WSL2在打开压缩的柏油球时运行速度快20倍,而在使用时运行速度快2-5倍 git克隆 和 cmake 关于各种项目。

在WSL1中,我们创建了一个转换层,它解释许多系统调用,并允许它们在Windows NT内核上工作。然而,实现所有这些系统调用是一项挑战,导致一些应用程序无法在WSL1中运行。
现在WSL2包含了自己的Linux内核 具有完全的系统调用兼容性 .