Aaron Sherman <a...@ajs.com> added the comment: "That's why I asked for absolute numbers for the overhead difference."
Did you not follow the link in my first post? I got pretty detailed, there. "os.popen just calls the popen(3) library call, which just performs a fork/execve and some dup/close in between. subprocess.Popen is implemented in Python, so it doesn't come as a surprise that it's slower in your example." Well, of course. I don't think I was ever trying to claim that os.popen vs. subprocess without a shell was going to compare favorably. I'm not advocating os.popen, here, I'm just trying to figure out where this massive overhead is coming from. I think the answer is just, "pure Python is fundamentally slower, and that's not a surprise." Now, if the 3.x subprocess work that was described here, gets back-ported into 2.x and is included with future releases, that will definitely serve to improve the situation, and might well render much of this moot (testing will tell). However, I do think that doing the performance testing before deprecating the previous interface would have been a good idea... ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11314> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
