subprocess.Popen 在 WSL Linux 上花费的时间太长 [英] subprocess.Popen taking too long on WSL Linux

问题描述

我有这个 subprocess.Popen() 上下文管理器:

I have this subprocess.Popen() context manager:

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)

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

And it seems to take 53 seconds to process list(process.stdout) when running in a WSL Linux enviorment. However, when I run it in a Windows enviorment, it only takes 0.6 seconds. I'm finding it strange to see why the timings are so different.

我试过使用 subprocess.run() 和 subprocess.check_output() 而不是，但在处理 tqdm() 循环之前，它们仍然会导致同样长的延迟.

I've tried using subprocess.run() and subprocess.check_output() instead, but they still lead to the same long lag before processing the tqdm() loop.

我在这里遗漏了什么吗?我已经尝试查看文档以了解在 Windows 与 WSL Linux 环境中使用 subprocess.Popen() 有什么区别，但我仍然不确定问题是什么.也许 list(process.stdout) 在这里是不必要的，并且有一种更好的方法来存储来自 stdout 的行.

Am I missing something here? I've tried looking at the docs to see what are the differences using subprocess.Popen() in a Windows vs WSL Linux enviorment, but I'm still unsure what the issue is. Perhaps list(process.stdout) is unnecessary here, and there is a better way to store the lines from stdout.

任何形式的指导在这里都会非常有帮助.

Any sort of guidance would be very helpful here.

推荐答案

Windows Subsystem for Linux 有点垃圾.它有很多很多错误，而且它比它需要的要慢得多.这只是另一个表现出来的错误.以下是一些可能的瓶颈:

Windows Subsystem for Linux is a bit rubbish. It's got many, many bugs and it's significantly slower than it needs to be. This is just another bug manifesting itself. Here are some possible bottlenecks:

• WSL 中的上下文切换缓慢.
• WSL 没有注意到等待管道的整个进程意味着现在应该运行管道的另一端.
• 延迟执行的子进程.
• Windows 需要一段时间才能确定它需要使用 wsl.exe 来启动程序(感谢 RoadRunner！)
• Windows 的常规开销，加上 Linux 的常规开销(相对较小).
• 一个糟糕的 Ubuntu 发行版选择导致许多不必要的服务在 systemd(?)
中运行
• Windows 出于某种未知原因决定在子进程之前运行其他内容.
• Windows 子系统对 Linux 开发人员的蓄意恶意，合谋通过设置稻草人来证明"Windows 是卓越的操作系统. 太愚蠢了.

• Slow context switching in WSL.
• WSL not noticing that an entire process waiting for a pipe means that the other end of the pipe should be run now.
• The child process being executed lazily.
• Windows taking a while to figure out that it needs to use wsl.exe to launch the program (thanks RoadRunner!)
• The usual overhead of Windows, plus the usual (comparatively small) overhead of Linux.
• A poor choice of Ubuntu distro causing many unnecessary services to be running in systemd(?)
• Windows deciding to run other stuff before the child process for some unknown reason.
• Deliberate malice on the part of the Windows Subsystem for Linux developers, conspiring to "prove" that Windows is the superior operating system by setting up a strawman. Too silly.

您的 Python 代码没有任何问题会导致速度变慢.

There's nothing wrong with your Python code that would make this slow.

这篇关于subprocess.Popen 在 WSL Linux 上花费的时间太长的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！