Comment by marshray
8 years ago
Here's what has worked for me:
1. Don't do that. Either write the driving app in Python or write the subprocesses in an ahead-of-time compiled language. Python's a great language but it's not the right tool for everything.
2. Be parsimonious with the modules you import. During development, measure the performance after adding new imports. E.g., one graph libraries I tried had all its many graph algorithm implementations separated into modules and it loaded every single one of them even if all you wanted to do was to create a data structure and do some simple operations on it. We just wrote our own minimal class.
> Don't do that. Either write the driving app in Python
Even if you write the driver in Python, you don't necessarily want to call the program you're testing in the same process. You might want independent launches of a command-line tool, so that you test the same behavior people get when they run the tool. Otherwise, your test suite might trip over some internal state that gets preserved from run to run in ways that command-line invocation wouldn't.
Good point, but I didn't mean to sound specific to testing apps. I just meant, in general, write big apps using Python top-down and something precompiled if you must spawn lots of external processes.
I've definitely seen significant improvements with #2. Unfortunately, it's not very Pythonic to tuck your imports into functions (or under conditionals). It would be nice if imports were more lazily evaluated.