Something new to this ??? Greets, Tobias.
Am Dienstag, 1. Juli 2014 21:44:16 UTC+2 schrieb Tobias Besemer: > Am Dienstag, 1. Juli 2014 14:05:39 UTC+2 schrieb David Rajchenbach-Teller: > > > Let's concentrate on Session Restore for the moment. > > > > OK, it was just because of the example and the need for a "Journaled Storage" > ... > > > > > > > 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. > > > > Yes. But as far as I understand it (and I can surly be wrong), a SQLite-DB is > always the same file. It grows, consolidate, maybe shrinks ... but always the > same file on "the same place" ... > > Working with sequential files creates always for some changes a file with > this changes, then creates a new one for the next changes ... then > consolidate, delete the old ones, creates a new and new files for the new > changes ... > > A lot of files gets written and then deleted again ... the file system > creates new files always on that places, that was deleted first ... this is > fragmentation ... the more files that gets written and deleted again, the > more fragmentation ... the head of the HD starts to "jump around" between the > files, need energy, need time, make the access slow ... > > Also a lot of small files waste a lot of unused space, because of using > always complete blocks on the HD ... > > > > > > > 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. > > > > I'm not really a programmer and I'm not really involved in the source ... but > whats about of a kind of "abstraction layer" ??? > > At first all can stay the same then before, just the ASCII File will be > replaced with a SQLite File with one table with one field. This should remove > that always the file gets new created (written). As far as I understand, a > ASCII File will be always new written, getting a new place on the HD, right? > An SQL File will be updated ... > > Later the cell can be spited / redesigned ... > > New APIs to write to the new cells ... > > The old API can be changed to trigger the new APIs ... > > ... and then should all be down-version compatible ... > > The old APIs can then be "deprecated" ... > > > > So, as I'm said, I don't be involved in the code of FF ... > > Is this much more work/harder then do the changes for the "Journaled Storage" > ??? > > > > FF is for the open web ... OK, a "Journaled Storage" is maybe readable with > an ASCII Editor ... but not really a standardized file format ... not much > usable for a power user or admin ... difficult for an programmer ... > > ... an SQLite DB can be opened, used, converted with a lot of programs ... I > think even LibreOffice can open it ... > > I used for the Places DB this one: > > https://sourceforge.net/projects/sqlitebrowser/ > > > > It's not that I persist on SQLite! > > It should be just a discussion about the pro and contras of it ... > > > > > > > Cheers, > > > > > > David > > > > Greets, Tobias. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
