WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
80358
[Chromium] IndexedDB: V8LocalContext creation in IDBKey extraction/injection is slow
https://bugs.webkit.org/show_bug.cgi?id=80358
Summary
[Chromium] IndexedDB: V8LocalContext creation in IDBKey extraction/injection ...
Joshua Bell
Reported
2012-03-05 17:19:39 PST
[Chromium] IndexedDB: V8LocalContext creation in IDBKey extraction/injection is slow
Attachments
Patch
(4.01 KB, patch)
2012-03-05 17:21 PST
,
Joshua Bell
no flags
Details
Formatted Diff
Diff
Patch
(4.08 KB, patch)
2012-03-06 15:27 PST
,
Joshua Bell
no flags
Details
Formatted Diff
Diff
Patch
(9.02 KB, patch)
2012-03-06 16:12 PST
,
Joshua Bell
no flags
Details
Formatted Diff
Diff
Patch
(8.24 KB, patch)
2012-03-07 11:35 PST
,
Joshua Bell
no flags
Details
Formatted Diff
Diff
Show Obsolete
(3)
View All
Add attachment
proposed patch, testcase, etc.
Joshua Bell
Comment 1
2012-03-05 17:21:14 PST
Created
attachment 130244
[details]
Patch
Joshua Bell
Comment 2
2012-03-05 17:24:15 PST
Dmitry, can you take a pre-review look at this CL and see if seems at all reasonable? When profiling with chrome://tracing the V8LocalContext creation was taking more than 90% of the time in these functions, and these functions represent the bulk of the time spent in the IndexedDB calls. With this change, time spent in IPC (renderer->browser, browser->utility) becomes the dominant factor. I don't have benchmarks yet, however.
Dmitry Lomov
Comment 3
2012-03-06 10:02:47 PST
Comment on
attachment 130244
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=130244&action=review
> Source/WebCore/bindings/v8/IDBBindingUtilities.cpp:173 > + AtomicallyInitializedStatic(ThreadSpecific<PersistentContext>*, instance = new ThreadSpecific<PersistentContext>);
I am not too happy about this. This will break if we will ever execute under 2 different v8 isolates on the same thread (you cannot share contexts between isolates because they have different heaps). Admittedly we do not do this today :) One solution to that would be to cache the context in V8BindingPerIsolateData instead. What do you think?
Joshua Bell
Comment 4
2012-03-06 11:55:39 PST
(In reply to
comment #3
)
> > I am not too happy about this. This will break if we will ever execute under 2 different v8 isolates on the same thread (you cannot share contexts between isolates because they have different heaps). Admittedly we do not do this today :) > One solution to that would be to cache the context in V8BindingPerIsolateData instead. What do you think?
I have no preference as to where we should cache the context; I'll look into V8BindingPerIsolateData
Joshua Bell
Comment 5
2012-03-06 15:27:36 PST
Created
attachment 130451
[details]
Patch
Joshua Bell
Comment 6
2012-03-06 15:35:30 PST
With a simple benchmark (1000 puts of an object into a store using a keyPath), the both the put() operations and the transaction tasks saw a 3-4x speedup.
Dmitry Lomov
Comment 7
2012-03-06 15:42:43 PST
Comment on
attachment 130451
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=130451&action=review
LGTM
> Source/WebCore/bindings/v8/IDBBindingUtilities.cpp:151 > +class V8AuxiliaryContext {
Remove V8LocalContext and replace all usages with V8AuxiliaryContext? (I see that the only other usages are in IDB tests)
Joshua Bell
Comment 8
2012-03-06 16:12:57 PST
Created
attachment 130461
[details]
Patch
Joshua Bell
Comment 9
2012-03-06 16:14:02 PST
(In reply to
comment #7
)
> > Source/WebCore/bindings/v8/IDBBindingUtilities.cpp:151 > > +class V8AuxiliaryContext { > > Remove V8LocalContext and replace all usages with V8AuxiliaryContext? > (I see that the only other usages are in IDB tests)
Ah, nice. *delete* *delete* Also clear out the context explicitly in the V8BindingPerIsolateData destructor.
Dmitry Lomov
Comment 10
2012-03-06 16:20:39 PST
Comment on
attachment 130461
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=130461&action=review
Still LGTM :)
> Source/WebCore/bindings/v8/V8Binding.cpp:64 > + m_auxiliaryContext.Dispose();
Not strictly necessary since isolate is going down anyway but nice to have
> Source/WebCore/bindings/v8/V8Utilities.cpp:68 > + V8BindingPerIsolateData::ensureInitialized(v8::Isolate::GetCurrent());
Tests won't pass without this? (if they won't let's have it)
Joshua Bell
Comment 11
2012-03-06 16:57:44 PST
(In reply to
comment #10
)
> (From update of
attachment 130461
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=130461&action=review
> > Still LGTM :) > > > Source/WebCore/bindings/v8/V8Binding.cpp:64 > > + m_auxiliaryContext.Dispose(); > > Not strictly necessary since isolate is going down anyway but nice to have
Ah, right - even Persistent<> handles are necessarily scoped to an isolate. (Learning as I go.)
> > Source/WebCore/bindings/v8/V8Utilities.cpp:68 > > + V8BindingPerIsolateData::ensureInitialized(v8::Isolate::GetCurrent()); > > Tests won't pass without this? > (if they won't let's have it)
Layout tests (under DRT) were hitting this w/o it: # Fatal error in ../../v8/src/isolate.h, line 439 # CHECK(isolate != __null) failed
Joshua Bell
Comment 12
2012-03-06 17:05:09 PST
Comment on
attachment 130461
[details]
Patch Hrm, now I'm seeing DRT crash on that check *with* that line. I must have mucked something up, so removing the r? for now.
Joshua Bell
Comment 13
2012-03-06 17:13:07 PST
(In reply to
comment #12
)
> (From update of
attachment 130461
[details]
) > Hrm, now I'm seeing DRT crash on that check *with* that line. I must have mucked something up, so removing the r? for now.
Huh, it was actually the destructor addition intermittently hitting that CHECK during the layout tests. Removed both, but need to run the full suite of tests before re-upping.
Dmitry Lomov
Comment 14
2012-03-06 17:23:04 PST
(In reply to
comment #13
)
> (In reply to
comment #12
) > > (From update of
attachment 130461
[details]
[details]) > > Hrm, now I'm seeing DRT crash on that check *with* that line. I must have mucked something up, so removing the r? for now. > > Huh, it was actually the destructor addition intermittently hitting that CHECK during the layout tests. Removed both, but need to run the full suite of tests before re-upping.
Oh right the destructor is called *after* isolate exited. Make sure that IDB unit test runs without ensureInitialized as well.
WebKit Review Bot
Comment 15
2012-03-07 03:14:51 PST
Comment on
attachment 130461
[details]
Patch
Attachment 130461
[details]
did not pass chromium-ews (chromium-xvfb): Output:
http://queues.webkit.org/results/11837943
New failing tests: storage/indexeddb/objectstore-count.html storage/indexeddb/index-count.html
Joshua Bell
Comment 16
2012-03-07 11:35:54 PST
Created
attachment 130658
[details]
Patch
Joshua Bell
Comment 17
2012-03-07 11:37:32 PST
Okay, this time for sure. Removed the cargo-cultisms. Specifically layout tests and webkit_unit_tests (IDBKeyFromValueAndKeyPathTest.*) that were concerns before, as well as the usual suite. abarth@ or tony@, r?
Dmitry Lomov
Comment 18
2012-03-07 11:57:47 PST
Comment on
attachment 130658
[details]
Patch Still LGTM :)
WebKit Review Bot
Comment 19
2012-03-07 14:30:05 PST
Comment on
attachment 130658
[details]
Patch Clearing flags on attachment: 130658 Committed
r110104
: <
http://trac.webkit.org/changeset/110104
>
WebKit Review Bot
Comment 20
2012-03-07 14:30:11 PST
All reviewed patches have been landed. Closing bug.
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