Closed Bug 1536497 Opened 5 years ago Closed 3 years ago

SandboxBrokerClient::DoCall takes lots of time when loading


(Core :: Graphics: CanvasWebGL, defect, P3)




Performance Impact high


(Reporter: smaug, Unassigned)



(Keywords: perf:pageload)

These all seem to be caused by OpenGL called from HTMLCanvasElement.getContext, which I assume means WebGL; that's being remoted in bug 1477756 but that's a longer-term project.

Inverting the call stacks, I notice that we're spending only 54% of the samples blocked in recvmsg and the rest in socketpair and close, which suggests that the problem is mostly broker overhead rather than the brokered operations themselves being slow. (Incidentally, it should be possible to also profile the broker itself by including FS Broker in the thread filter, but that may not be very informative.)

I notice that the larger profile (outside the time window selected in that link) also has a few samples from graphics allocating shared memory; bug 1440203 will help with that.

Component: DOM: Content Processes → Canvas: WebGL
Whiteboard: [qf] → [qf:p1:pageload]

ni? me to see if I can reproduce this and/or get data on how long the broker calls are taking. I have a small C program that does the same syscalls (created as a test case for a kernel bug, but also works as a microbenchmark), and it takes on the order of 10 µs per RPC, which is a lot less than what the profile here suggests.

Flags: needinfo?(jld)
Priority: -- → P3

I tried reproducing this with a WebGL demo (, although I'm using the nvidia proprietary drivers rather than Mesa/DRI.

Comment #0: 136ms in HTMLCanvasElement.getContext, of which 78ms in SandboxBrokerClient

Here: 83ms and 18ms, 73ms and 13ms, 94ms and 18ms

Here, no sandboxing: 57ms, 77ms, 90ms

Leaving the ni? because I also want to add instrumentation to see how much time each call is taking.

(In reply to Jed Davis [:jld] ⟨⏰|UTC-6⟩ ⟦he/him⟧ from comment #1)

it should be possible to also profile the broker itself by including FS Broker in the thread filter

Actually no, because they're not registered with the profiler. That could be fixed.

I'm probably not going to have time to look into this any time soon.

Flags: needinfo?(jld)

Can't seem to repro anymore. Please reopen if you see this again.

Closed: 3 years ago
Resolution: --- → WORKSFORME
OS: Unspecified → Linux
Hardware: Unspecified → Desktop
Performance Impact: --- → P1
Keywords: perf:pageload
Whiteboard: [qf:p1:pageload]
You need to log in before you can comment on or make changes to this bug.