Closed Bug 689235 Opened 10 years ago Closed 10 years ago

We need raw data on thread performance


(Core :: General, defect)

Not set





(Reporter: Yoric, Assigned: Yoric)


(Keywords: perf, platform)


(2 files)

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.
Attached file 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: .

For comparison, results of same protocol executed on Macintosh may be found here: .
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.
Attachment #563714 - Attachment is patch: true
Attachment #563714 - Attachment mime type: application/x-sh → text/plain
Measures seem satisfying and sufficient. Closing this bug.
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.