This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author josh.r
Recipients Alexander.Pyhalov, josh.r
Date 2019-08-08.01:26:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1565227569.96.0.690447866083.issue37790@roundup.psfhosted.org>
In-reply-to
Content
Have you tried switching to using Popen itself (or run, which keeps it to one layer of convenience wrapping)?

subprocess.getstatusoutput is three layers of wrapping (it calls check_output, which in turn calls run, which in turn calls Popen), and (unlike Python 2) has to decode all the output. run would avoid two layers of wrapping, can optionally receive the raw bytes instead of decoding to str, and avoids needing to wrap the whole thing in a shell (which system, older popen, and getstatusoutput all do).

Beyond that, it looks like when 3.8 releases, Popen should get *much* faster if the call meets certain conditions, see https://docs.python.org/3.8/whatsnew/3.8.html#optimizations for details. If you can make your use cases conform to those requirements (e.g. by using shutil.which to determine the absolute paths to your utilities instead of relying on PATH lookup), the speed up should eliminate (or more than eliminate) the performance regression you're seeing (per #35537, on macOS, which got the least benefit, it was still a 1.7x improvement; on other OSes, the multiplier hits 61x or 106x).
History
Date User Action Args
2019-08-08 01:26:09josh.rsetrecipients: + josh.r, Alexander.Pyhalov
2019-08-08 01:26:09josh.rsetmessageid: <1565227569.96.0.690447866083.issue37790@roundup.psfhosted.org>
2019-08-08 01:26:09josh.rlinkissue37790 messages
2019-08-08 01:26:09josh.rcreate