699621 - Unpack search.sqlite from omni.jar when profile is created

Status: RESOLVED WONTFIX

(Toolkit :: Find Toolbar, defect)

Description

[Vladan Djeric (:vladan)]

Attachment: Code for unpacking the DB when profile is created

To improve first run performance, we will be unpacking pre-created SQLite databases from omni.jar on profile initialization (see bug 691268).

This change extracts search.sqlite from omni.jar when the database doesn't exist. The extracted DB contains the DB schema but no rows. If extraction fails for whatever reason, an error is logged and the DB is created from scratch as before.

Comment 1

[Dave Townsend [:mossop] (PTO until Aug 21st)]

Comment on attachment 571814 [details] [diff] [review]
Code for unpacking the DB when profile is created

Is there a reason we're not using the zipreader cache for omnijar rather than individual (presumably expensive to init) zipreaders?

Comment 2

[Vladan Djeric (:vladan)]

(In reply to Dave Townsend (:Mossop) from comment #1)
> Comment on attachment 571814 [details] [diff] [review] [diff] [details] [review]
> Code for unpacking the DB when profile is created
> 
> Is there a reason we're not using the zipreader cache for omnijar rather
> than individual (presumably expensive to init) zipreaders?

Are ZipReaders expensive to initialize? The omni.jar archive is only ever opened once.. The only potentially expensive ZipReader constructor operation is initializing the mutex (nsJAR::mLock), and that doesn't seem to be particularly expensive

Comment 3

[Mike Hommey [:glandium]]

That won't work for non-omni.jar builds. You should just use resource://gre/ urls (which also will reuse the already opened omnijar's ZipArchive).

Comment 4

[Mike Hommey [:glandium]]

Also note your patch won't work on mobile builds where the omni.jar is the apk (and soon it will even be a jar-in-the-apk).

Comment 5

[:Gavin Sharp [email: [e-mail]]]

I'm a bit confused, doesn't this also need a "package an empty search.sqlite in omni.jar" part? Is that in some other bug?

Comment 6

[:Gavin Sharp [email: [e-mail]]]

Ah, nevermind, I see that that's in bug 691268's patch.

Comment 7

[David Teller [:Yoric] - still alive but not very active]

Vladan, for bug 699856, I am currently fully getting rid of search.sqlite. So, if you are not done yet, do not spend too much time on this bug.

Comment 8

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 571814 [details] [diff] [review]
Code for unpacking the DB when profile is created

Given David and Mike's comments, I don't think we want to take this now. We can revisit if the search.sqlite-ectomy fails :)

Comment 9

[:Gavin Sharp [email: [e-mail]]]

bug 691268 is WONTFIX, and search.sqlite no longer exists (bug 699856)