Closed Bug 1641614 Opened 8 months ago Closed 5 months ago

Reduce IPC queue overhead


(Core :: IPC, task, P3)




81 Branch
Tracking Status
firefox81 --- fixed


(Reporter: mccr8, Assigned: mccr8)


(Blocks 1 open bug)


(Whiteboard: [overhead:52k])


(2 files)

I see about 52kb of what look like mostly-empty queues, plus another 12kb in non-totally-empty queues in IPC code. It would be nice if we could reduce this overhead. I think nsDeque scales down better, but it is a pretty ugly data structure so maybe that's not great. If these queues are mostly sitting completely empty, then maybe they could be converted to Maybe<queue> or something so they won't use memory when empty.

Here are the unreported stacks for a small content process with deque in them (which is what implements queue).

It looks like there's a total of about 70,000 bytes of std::deque memory being used, though the rest of the stacks look the same as what I already attached.

Kashav said he isn't seeing these stacks on Linux, so maybe the std lib on OSX is somehow different and doing something worse? Or maybe there's just a difference in inlining that affects the stacks.

froydnj pointed out a comment in the code added by bug 1241656 where njn fixed a similar issue with another queue. That would be worth reading.

See Also: → 1241656

Apparently there's even a mozilla::Queue now, so that's another option.

Assignee: nobody → continuation
Depends on: 1642631

I changed ChannelImpl::output_queue_ to use mozilla::Queue instead of std::queue. It reduces the size of each from 4kb to 2kb, which is something. I can adjust the size parameter, and/or switch it to a Maybe<Queue>. I'm not sure how much ends up in these queues in normal circumstances.

I did some unscientific experiments with printfing the output queue length when a message is added. (This was on Linux and with a debug build; opt builds might have different results because of timing differences.) The vast majority (>99.8%) of messages are the only one in the queue while pending; PContent would spike to 20-25 during startup, and there were a few spikes up to around 8 during a reload.

So, setting the size parameter to something small like 8 or even 2 (it subtracts 1, so 2 would turn it into a simple linked list) might not be a problem.

Pushed by
Use mozilla::Queue for ChannelImpl::output_queue_h_. r=froydnj
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → 81 Branch
You need to log in before you can comment on or make changes to this bug.