Let's concentrate on Session Restore for the moment. Adopting a Journaled Storage will let us decrease the total amount of I/O. Once we have sufficiently fine-grained differential updates, either Journaled Storage or Sqlite would allow us to change only a single tab (or even a single attribute). Both Journaled Storage and Sqlite also need to consoldate their data.
It is possible that Sqlite would be more efficient than Journaled Storage for this use case. At this stage, I cannot tell. However, it is certain that Sqlite would kill all existing add-ons and recovery mechanisms for Session Restore, while Journaled Storage would not, so Sqlite would need to be much, much better than Journaled Storage to justify such a migration. Cheers, David On 01/07/14 00:39, Tobias Besemer wrote: > At first it was just a comment to the bug you mentioned ... about "Journaled > Storage" ... and the example there with bookmarks backup ... and that I don't > think that this is necessary for this ... > So if we have to first to talk about a other storage solution ... about a > "Journaled Storage" ... we have to talk maybe first for what it is needed ... > if really for a backup of the bookmarks/places ... ??? > Other topic for that ??? > > And if the SQLite writes just the changing tab(s), it should be less I/O then > writing all the time the complete JSON, or ??? > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > -- David Rajchenbach-Teller, PhD Performance Team, Mozilla
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
