Projects/KDE PIM/Development/Mobile/ResourcesCESearch: Difference between revisions
(first keywords to next steps) |
(smaller updates) |
||
(One intermediate revision by one other user not shown) | |||
Line 6: | Line 6: | ||
:# real search dialog (_not_ quicksearch) | :# real search dialog (_not_ quicksearch) | ||
:# to-field autocompletion | :# to-field autocompletion | ||
:# | :# MemoryCalendarMemento (could be replaced with IncidenceFetchJob though) | ||
* how much memory does strigidaemon actually use? | * how much memory does strigidaemon actually use? (Can be found with taskmanager, 1936kb here on an empty device, says Andre) | ||
* how much memory does strigiindexer use (sees more on the desktop) | |||
* check if clucene used by strigidaemon cannot be tuned to use less memory | * check if clucene used by strigidaemon cannot be tuned to use less memory | ||
* implement a display of the last index run, e.g on the search page | * implement a display of the last index run, e.g on the search page |
Latest revision as of 15:36, 9 February 2011
On Windows Mobile 6.5 (CE) Kontact Touch has a resource problem, the searching and indexing is done via strigifeeder and strigidaemon.
Next steps:
- find all places where search is needed
- real search dialog (_not_ quicksearch)
- to-field autocompletion
- MemoryCalendarMemento (could be replaced with IncidenceFetchJob though)
- how much memory does strigidaemon actually use? (Can be found with taskmanager, 1936kb here on an empty device, says Andre)
- how much memory does strigiindexer use (sees more on the desktop)
- check if clucene used by strigidaemon cannot be tuned to use less memory
- implement a display of the last index run, e.g on the search page
- implement a button to trigger a manual index, e.g. on the search page (both can be reused once we come up with an idea when the indexer should run.)
- Can we reliably see if the device is under low load, e.g. if only one or no frontend is running?
Options as tokoe saw them 2011020914:32:
1) A UI option to switch strigi_feeder between online/offline mode
pro: The strigi_feeder in offline mode wouldn't index anything until it is switched back to online mode. So it would take away pressure on the device during initial sync, since CPU and I/O usage is reduced.
contra: Since recent data are not indexed with strigi_feeder in offline mode, some internal searches might not return the correct, or better said 'expected', data. Switching the strigi_feeder to online mode automatically when a search is started is not really an option, because feeding the new data to strigidaemon takes a while, so they won't be included in the current search results.
costs: We have to extend strigi_feeder to correctly record actions during offline mode and replay them when switched to online mode. Furthermore we need options in the UI to switch the mode of the strigifeeder (Ideas from Björn Balazs?).
2) IDLE detection in strigidaemon with automatic shutdown
pro: Afaik strigidaemon uses lots of memory when running, so stopping strigidaemon whenever no indexing or search is done, should provide some free memory on the device.
contra: Searches are done quite often (e.g. the autocompletion in mail composer) and strigi_feeder will index data as soon as something changes (e.g. read flags in emails), so I doubt that strigidaemon will have long idle sessions. Strigidaemon might cause additional costs during its startup/shutdown phase.
costs: We have to implement an idle detection in strigidaemon (non qt-based!) and a clean shutdown procedure. Furthermore we have to extend akonadiserver to handle the disappearance of strigi dbus interface gracefully and restart the strigidaemon on demand. This needs a lot of testing!
It would be possible to combine 1) and 2), but this will increase the number of side effects, so much more testing is needed.