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 vstinner
Recipients Aaron.Sherman, giampaolo.rodola, gregory.p.smith, neologix, pitrou, vstinner
Date 2011-03-02.12:11:00
SpamBayes Score 1.9561146e-05
Marked as misclassified No
Message-id <1299067862.29.0.175389632467.issue11314@psf.upfronthosting.co.za>
In-reply-to
Content
Quick benchmark:
 - fork(), execv(), waitpid(): 19081.1 ms
 - os.popen(): 25769.8 ms
 - subprocess.Popen(): 40025.8 ms
 - subprocess.Popen() patched: 26155.2 ms

I tested Python 2.7 (debug build) on Linux (Debian Sid) with a Pentium 4 (Hyperthreading, 2 fake cores), 2 GB of memory.

Without the patch, subprocess is 55% slower than popen. With the patch, subprocess is 1% slower than popen. It is not a good news: subprocess should be faster before my benchmark tries Popen() without stdout=PIPE ;-)

pitrou> I think your analysis is wrong. These mmap() calls are for
pitrou> anonymous memory, most likely they are emitted by the libc's
pitrou> malloc() to get some memory from the kernel. In other words
pitrou> they will be blazingly fast.

Are you sure? :-)

Note that popen() is 35% slower than fork()+execv()+waitpid(). Patched subprocess is 37% slower than  fork()+execv()+waitpid().

Try attached bench_subprocess.py script to get your own results.
History
Date User Action Args
2011-03-02 12:11:02vstinnersetrecipients: + vstinner, gregory.p.smith, pitrou, giampaolo.rodola, neologix, Aaron.Sherman
2011-03-02 12:11:02vstinnersetmessageid: <1299067862.29.0.175389632467.issue11314@psf.upfronthosting.co.za>
2011-03-02 12:11:00vstinnerlinkissue11314 messages
2011-03-02 12:11:00vstinnercreate