Reduce IPC queue overhead
Categories
(Core :: IPC, task, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox81 | --- | fixed |
People
(Reporter: mccr8, Assigned: mccr8)
References
(Blocks 1 open bug)
Details
(Whiteboard: [overhead:52k])
Attachments
(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.
Assignee | ||
Comment 1•4 years ago
|
||
Here are the unreported stacks for a small content process with deque in them (which is what implements queue).
Assignee | ||
Comment 2•4 years ago
|
||
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.
Assignee | ||
Comment 3•4 years ago
|
||
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.
Assignee | ||
Comment 4•4 years ago
|
||
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.
Assignee | ||
Comment 5•4 years ago
|
||
Apparently there's even a mozilla::Queue now, so that's another option.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 6•4 years ago
|
||
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.
Comment 7•4 years ago
|
||
I did some unscientific experiments with printf
ing 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.
Assignee | ||
Comment 8•4 years ago
|
||
Comment 10•4 years ago
|
||
bugherder |
Description
•