The way that threading works must be improved
Right now the data access object (DAO) spawns a thread to parse the note. This doesn't work. For example, having 200 notes will spawn 200 threads.. with the cost associated to spawn a thread this is simply stupid.
Blueprint information
- Status:
- Complete
- Approver:
- Olivier Bilodeau
- Priority:
- High
- Drafter:
- Olivier Bilodeau
- Direction:
- Approved
- Assignee:
- Olivier Bilodeau
- Definition:
- Approved
- Series goal:
- Accepted for stable
- Implementation:
-
Implemented
- Milestone target:
-
0.2
- Started by
- Olivier Bilodeau
- Completed by
- Olivier Bilodeau
Whiteboard
Suggested implementation: thread pool will be initializated in the code that lists the *.note files and each note will be assigned a thread to work on it. Once the thread returns the note will be added to the note list and the thread will be given another note until everything has been processed.
Tests should be run for a thread pool of 1, 3, 5 or more threads and a value selected based on the better performance.
------------
ok, did several tests through this. Cached pool is a bad idea (spawns almost as many threads as there are notes) and a fixed thread of 3 is still making the device's ui a little sluggish..
We will decide between a fixed thread pool of 3 threads and 1 thread. With 1 thread responsiveness is good and we'll check the benchmarking, with 3 responsiveness is worse but if its faster we'll have to decide.
Turns out that this work doesn't improve performance much if at all (as you can see below), only responsiveness is enhanced.
----------
Benchmarking information:
(taken from doc/dev/
Benchmarks
As of 0.1.0 release
===================
@ revno 84 of branch threading-
applying patch benchmark-r84.patch
4 demo notes (emulator on Windows)
cold average: 4150ms
hot average: 800ms
50 demo notes (emulator on Windows)
cold average: 10880ms
hot average: 6800ms
IO and parsing done in one thread per file
=======
@ revno 86 of branch threading-
applying patch benchmark-r84.patch
4 demo notes (emulator on Windows)
cold average: 3541ms
hot average: 700ms
50 demo notes (emulator on Windows)
cold average: 10093ms
hot average: 6320ms
No temporary string, read file from XML parser
=======
@ revno 88 of branch threading-
applying patch benchmark-r84.patch
4 demo notes (emulator on Windows)
cold average: 3936ms
hot average: 800ms
50 demo notes (emulator on Windows)
cold average: 9300ms
hot average: 6400ms
Runnable NoteBuilder instead of a DAO
=======
@ revno 91 of branch threading-
applying patch benchmark-r84.patch
4 demo notes (emulator on Windows)
cold average: 3400ms
hot average: 550ms
50 demo notes (emulator on Windows)
cold average: 13000ms
hot average: 6800ms
Executor service launching worker threads (AsyncNoteLoade
=======
@ revno 95 of branch threading-
applying patch benchmark-r84.patch
== SDK 1.0r1 ==
Fixed Thread Pool (pool size 3)
4 demo notes (emulator on Windows)
cold average: 4400ms
hot average: 750ms
50 demo notes (emulator on Windows)
cold average: 9000ms
hot average: 6400ms
Fixed Thread Pool (pool size 5)
4 demo notes (emulator on Windows)
cold average: 3500ms
hot average: 600ms
50 demo notes (emulator on Windows)
cold average: 10000ms
hot average: 6400ms
Cached Thread Pool (reusable threads)
4 demo notes (emulator on Windows)
cold average: 4200ms
hot average: 600ms
50 demo notes (emulator on Windows)
cold average: 10048ms
hot average: 6300ms
Looking at the traceview traces, the usage pattern of the fixed thread is
better than the cached thread pool (which spawns almost 50 threads anyways)
== SDK 1.1r1 ==
Fixed Thread Pool (pool size 1)
real device ADP1 ~52 notes
cold average: 16000ms
hot average: 8150ms
responsiveness: ui refreshes but scrolling / opening notes is too slow
Fixed Thread Pool (pool size 2)
real device ADP1 ~52 notes
cold average: 13000ms
hot average: 7250ms
responsiveness: ui refreshes but scrolling / opening notes is too slow
