Closed
Bug 1306928
Opened 8 years ago
Closed 8 years ago
Document cookie getter can be slow with e10s
Categories
(Core :: Networking: Cookies, defect)
Core
Networking: Cookies
Tracking
()
RESOLVED
DUPLICATE
of bug 1331680
Tracking | Status | |
---|---|---|
firefox52 | --- | affected |
People
(Reporter: bzbarsky, Unassigned)
References
Details
(Whiteboard: [necko-next])
My browser was just being laggy, and profiling showed that a bunch of time in the content process was spent waiting on condvars with this stack:
js::jit::DoCallNativeGetter(JSContext*, JS::Handle<JSFunction*>, JS::Handle<JSObject*>, JS::MutableHandle<JS::Value>) (in XUL) + 110 [0x10ba3868e]
mozilla::dom::GenericBindingGetter(JSContext*, unsigned int, JS::Value*) (in XUL) + 382 [0x109a2241e]
mozilla::dom::HTMLDocumentBinding::get_cookie(JSContext*, JS::Handle<JSObject*>, nsHTMLDocument*, JSJitGetterCallArgs) (in XUL) + 163 [0x10997b363]
nsHTMLDocument::GetCookie(nsAString_internal&, mozilla::ErrorResult&) (in XUL) + 292 [0x109cdd884]
mozilla::net::CookieServiceChild::GetCookieStringInternal(nsIURI*, nsIChannel*, char**, bool) (in XUL) + 537 [0x107f9a959]
mozilla::net::PCookieServiceChild::SendGetCookieString(mozilla::ipc::URIParams const&, bool const&, bool const&, mozilla::NeckoOriginAttributes const&, nsCString*) (in XUL) + 533 [0x1089a5415]
mozilla::ipc::MessageChannel::Send(IPC::Message*, IPC::Message*) (in XUL) + 1899 [0x10840f49b]
PR_WaitCondVar (in libnss3.dylib) + 255 [0x107c7a94f]
That's a web page doing document.cookie, which calls into the cookie service, which starts doing sync IPC to the parent process...
I thought we cached cookies in the child process, at least to some extent. If we don't, can we?
Updated•8 years ago
|
Whiteboard: [necko-next]
Comment 1•8 years ago
|
||
(In reply to Boris Zbarsky [:bz] (still a bit busy) from comment #0)
> I thought we cached cookies in the child process, at least to some extent.
> If we don't, can we?
With multiple processes, this gets complicated since we'd have to invalidate the cache in all child processes whenever we change the cookie for any given domain. We held off on doing this because of that complexity but I guess we could implement a cache if we needed to.
![]() |
Reporter | |
Comment 2•8 years ago
|
||
> this gets complicated since we'd have to invalidate the cache in all child processes
That's true. Do we need to do it synchronously, or can we do it async? I guess we'd more or less have to do it synchronously so you can log in in one window and then in another one navigate to the same site and seem logged in? But the sync bit would only need to be the call to the parent; once the parent receives the updated value and sends out async cache updates to the other processes it seems like we would be fine. That's not worse, performance-wise than our current setup where any cookie write _or_ read is a sync call to the parent, right?
Comment 3•8 years ago
|
||
Being addressed in Bug 1331680, specific plan in Bug 1331680 Comment 14.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•