WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
65306
WebKitInitializeStorageIfNecessary() can take awhile performing i/o, isn't necessary for every WebView
https://bugs.webkit.org/show_bug.cgi?id=65306
Summary
WebKitInitializeStorageIfNecessary() can take awhile performing i/o, isn't ne...
Brady Eidson
Reported
2011-07-28 00:34:05 PDT
WebKitInitializeStorageIfNecessary() can take awhile performing i/o, isn't necessary for every WebView Right now we blindly call WebKitInitializeStorageIfNecessary the moment the first WebView is created. Since it can do some (sync) i/o, this can be a waste of time if storage tracking will never be needed (APIs aren't called, or LocalStorage is never used). There's room to make it better by making it asynchronously initialize on a background thread, but in the meantime let's defer it until it's actually needed. In radar as <
rdar://problem/9714337
>
Attachments
Patch v1 - Move the hefty work from StorageTracker::initializeTracker() until the first time the global tracker is actually accessed.
(9.29 KB, patch)
2011-07-28 00:59 PDT
,
Brady Eidson
mjs
: review+
beidson
: commit-queue-
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Brady Eidson
Comment 1
2011-07-28 00:38:47 PDT
By moving the "one time initialization" code into StorageTracker::tracker(), this ensures that the initialization will take place: 1 - Before anyone in WebCore needs to use the shared StorageTracker object 2 - Before any API in WebKit/WebKit2 needs to use the shared StorageTracker object
Brady Eidson
Comment 2
2011-07-28 00:46:38 PDT
Filed
https://bugs.webkit.org/show_bug.cgi?id=65308
since I noticed that StorageTracker::setClient() and the associated client guard mutex are pretty much irrelevant.
Brady Eidson
Comment 3
2011-07-28 00:59:17 PDT
Created
attachment 102240
[details]
Patch v1 - Move the hefty work from StorageTracker::initializeTracker() until the first time the global tracker is actually accessed.
Maciej Stachowiak
Comment 4
2011-07-28 01:44:06 PDT
Comment on
attachment 102240
[details]
Patch v1 - Move the hefty work from StorageTracker::initializeTracker() until the first time the global tracker is actually accessed. r=me
Brady Eidson
Comment 5
2011-07-28 08:33:12 PDT
http://trac.webkit.org/changeset/91931
Joseph Pecoraro
Comment 6
2011-07-28 11:21:08 PDT
Comment on
attachment 102240
[details]
Patch v1 - Move the hefty work from StorageTracker::initializeTracker() until the first time the global tracker is actually accessed. View in context:
https://bugs.webkit.org/attachment.cgi?id=102240&action=review
> Source/WebCore/storage/StorageTracker.h:115 > + bool m_isInitialized;
What value does this boolean add, or is there more planned for it in the future?
Brady Eidson
Comment 7
2011-07-28 11:29:36 PDT
(In reply to
comment #6
)
> (From update of
attachment 102240
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=102240&action=review
> > > Source/WebCore/storage/StorageTracker.h:115 > > + bool m_isInitialized; > > What value does this boolean add, or is there more planned for it in the future?
Initialization has to be separate from construction - that's the purpose of the patch. There is one case where we construct a "dummy" tracker and immediately initialize it, but in the StorageTracker::initializeTracker(const String&, StorageTrackerClient*) case, we construct with the intent to initialize later.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug