In a recent dev.platform discussion it came up that the overhead for individual workers is noticeable in about:memory, due to each worker havings its own runtime, GC arena, etc. A possible short-term improvement could be to consolidate workers - what are now separate workers could be shared in one worker, with the message handling code routing to the right one. This can't work if the workers are long-running and need to run in parallel, of course (and even if short-running, it would decrease use of multiple cores, but on single-core phones that might not matter much). Not sure what the situation is with the relevant workers, opening this bug for discussion/investigation.
Relevant discussion: https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.platform/XMkcvEAeA60
From jlebar's about:memory as linked in that discussion, the relevant workers are ril_worker.js net_worker.js and two wifi_worker.js
Not sure who mainly works on these files, so cc'ing some people that I see in the hg logs for them. Any thoughts on the feasibility of this bug would be welcome, and sorry if I am cc'ing the wrong people.
It was pointed out to me that we don't (usually? ever?) use the Gecko RIL in production. If that's true, we only would need to merge the other three workers.
(In reply to Justin Lebar [:jlebar] from comment #4) > It was pointed out to me that we don't (usually? ever?) use the Gecko RIL > in production. If that's true, we only would need to merge the other three > workers. Depends on which chipset we're running. For now, production chipsets are all the same, so I'd call it "usually" but not "ever".
The whole reason that these things are workers to begin with is that they block on reading/writing to special file descriptors. We'd need to change from a single-fd to a multiple-fd system and then figure out where to deliver the data. We'd also have fun dealing with the case of trying to write to an fd while there's an incoming call, etc. Then we'd have to merge the main thread scripts to route the incoming messages as well... I'd say this is doable but not trivial.
> The whole reason that these things are workers to begin with is that they block on reading/writing > to special file descriptors. That was the key piece of data I needed. Sounds like we shouldn't do this.