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] Protocol 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.