Message129880
| 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. |
|