At start-up, we have sometimes 80+ threads (see bug 611837). Probably not a big issue on desktop platforms, but might be problematic on mobile.
We need some idea of thread-related costs on mobile platforms (and, possibly, at a later stage, other platforms).
In particular, areas of interest are:
- virtual memory allocated at thread creation;
- actual memory allocated at thread creation;
- time spent creating/destroying a thread;
- speedup for I/O tasks.
Created attachment 563064 [details]
I have put together a simple cross-platform benchmark. It consists in two tests.
The first one is CPU-bound: for each number of threads between 1 and 100, given a constant amount of CPU-bound work, spawn p-1 threads, divide the work between the p threads, wait until all threads have finished their work, then proceed. Measure time and memory usage.
The second test is IO-bound. The protocol is similar, but the work consists in reading and writing arbitrary data to/from temporary files.
I attach the protocol.
Results may be found here: https://docs.google.com/spreadsheet/ccc?key=0AsDW-iLj4J3pdGNNc3g2alpES0NlZndCR2NXWmdGTUE&hl=en_US .
For comparison, results of same protocol executed on Macintosh may be found here: https://docs.google.com/spreadsheet/ccc?key=0AsDW-iLj4J3pdEZCVmlfdnF1YUNXN1RRU3NuTUdSblE&hl=en_US .
Initial exploitation of data: Android seems to handle threads very well. Exploiting the dual core of the Galaxy Tab, both the CPU-bound test and the IO-bound see a 2x speedup when using 2 threads, and doesn't get noticeably worse when we progressively grow to 100 threads. Memory usage is reasonably constant no matter how many threads are used.
I am not sure how to interpret the linear growth of page reclaims.
Created attachment 563714 [details] [diff] [review]
Quick-and-dirty build script, in case anyone needs it
Measures seem satisfying and sufficient. Closing this bug.