RESOLVED FIXED65306
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-
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
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.