1163210 - Use a single database version for each database

Status: RESOLVED FIXED

(Firefox for iOS :: Data Storage, defect)

Description

[Richard Newman [:rnewman]]

Right now we have a schema table that manages a set of virtual 'tables'.

That means on startup we do a bunch of work: we create or update the schema table itself, then we query the schema table to decide whether to create or update the virtual tables. If any of them need to be updated, we might do an existence check, then make the change, then we run an update against the schema table itself.

On first run the story is even worse: check for schema table; create schema table; query schema table; create every other table; for each individual table, update the schema table. We touch browser.db perhaps a dozen times on startup.

We should pare this down as much as possible, perhaps even to the point of solely using the database version number itself, as we do on Android.

Bug 1160399 is a step towards this: BrowserTable consolidates four tables and three views, but still hooks into the Table mechanism.

Comment 1

[Wesley Johnston (:wesj)]

This is probably micro-optimization. I'm not even sure its that. I mean, most of the hard work you mention above happens in any case. i.e. we check a version in the db, decide whether to create or update the tables based on that. If any of them need to updated, we do existence checks, make the changes, and then update the db version itself (and if ANY of them fail).

Right now we DON'T have to create every table on first run, precisely because of this. We just create the ones we need, which are probably history, favicons, visits, and some join tables between them. In most cases, they probably exist and are the right versions, so we probably just go "hey, do i have version 1 of this, yup!" and are done. That's opposed to a single "Hey is the db version 1. Yup" call, but since we only have 6? (a dozen?) maybe tables, its a trivial amount of time. We could slurp up the versions db into a cursor and not requery it if we don't need to (its 6 rows long, so holding it in memory is probably trivial). I expect sqlite already does, making these queries basically zero time operations. I'd be happy to move them into a transaction if they aren't already (but at one point they were...)

In fact, its even nicer than that because, even though one table needs an upgrade, the rest can go about their business happily. i.e. upgrading the logins table doesn't have to happen at startup, and doesn't have to bother the other tables when it happens. I'm dubious there's a good optimization here (and dont't seen any data to show there's a problem).

Comment 2

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Is this measurable? I did not see any of this code run when I was profiling the app. We need some numbers first before we start optimizing this.

Comment 3

[Richard Newman [:rnewman]]

All perf bugs have an implied "measure this and decide" clause :)

Comment 4

[Stephan Leroux [:sleroux]]

Attachment: Image

Looks like this is somewhat a concern when profiling my first gen iPad mini but there are some other issues that look more pressing.

Comment 5

[Richard Newman [:rnewman]]

This was removed a few releases ago, IIRC by justindarc.