> The point about CPU usage and battery life is concerning.
> For Firefox hub, we chose to use SQLite to back the home panel data…
Forewarned is forearmed. It's worth noting that not using SQLite can involve
other kinds of complexity — home panel data is written from Gecko and read from
Java, potentially written interleaved from different contributors, and might
have additive or replace-all semantics, as well as storing data for multiple
sources.
Addressing all of those with a flat-file approach isn't straightforward.
> … and I'm wondering if there are any measurements we can perform to see if it
> might be worth changing this implementation in the future. I filed bug 987238
> about adding a telemetry probe for the size of that DB. At this point, we're
> going to ship this feature with SQLite, but we could switch the backend in
> the future if we decide it's worth it.
Sounds like the right approach to me. Also worth measuring other sqlite files
(shm, wal, any post-crash fragments) — those need tuning, too.
Longer term we'd like to be correlating visible power spikes with feature
events, and being able to run 'slices' of Fennec to study their power impact,
which will probably benefit from more telemetry and simple logging.
In the short term, we can get an informal impression just by seeing how long it
takes to go from opening the DB to getting cursor results (most of that time
will either go to CPU or flash access), and eyeballing mfinkle's power graphs.
_______________________________________________
mobile-firefox-dev mailing list
mobile-firefox-dev@mozilla.org
https://mail.mozilla.org/listinfo/mobile-firefox-dev
