forked from mozilla/gecko-dev
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Bug 1627075 - Allow lazily initializing nsZipArchives r=froydnj
Opening our Omnijars can be expensive, and it should be deferrable until after startup is completed, provided we have a startup cache. In a previous patch in this stack, we implemented caching of the zip central directory for omnijars, but we still have to open the file in order to hand the object off to various omnijar consumers. In a later patch, we will wrap nsZipArchive access in a class which will allow us to transparently cache nsZipArchive results. These two get us most of the way to not needing to read from the underlying omnijar files during startup, but there are still nontrivial pieces, like nsZipFind for instance, which we don't want to just duplicate inside of a wrapper class, so we would like to sort out a way in which we can use an nsZipArchive class, but not actually back it up with the real underlying file until we really need data from it which we can't find in a cache. Depends on D77633 Differential Revision: https://phabricator.services.mozilla.com/D78584
- Loading branch information
1 parent
fafe31f
commit 2046625
Showing
3 changed files
with
249 additions
and
36 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.