Hi > On 11 Jul 2018, at 10:10 pm, Kris Maglione <kmagli...@mozilla.com> wrote: > Thanks. Boris added this as a blocker. > > It looks like it will be helpful, but unfortunately won't give us the 2MB > simple arithmetic would suggest. On Windows, at least, (and probably > elsewhere, but need to confirm) thread stacks are lazily committed, so as > long as the decoders aren't used in a process, the overhead is probably > closer to 25KB per thread. > > Shrinking the size of the thread pool and lazily spinning up threads when > they're first needed would probably save us 200KB per process, though...
I haven’t looked much in details, not being an expert on this and having just finished watching the world cup… A quick glance at the code gives me: On mac/linux using pthread: when a thread is created, the stack size is set using pthread_attr_setstacksize https://searchfox.org/mozilla-central/source/nsprpub/pr/src/pthreads/ptthread.c#355 On Linux, the man page is clear: "The stack size attribute determines the minimum size (in bytes) that will be allocated for threads created using the thread attributes object attr.” On mac, less so, I’m not sure what’s the behaviour there is, if it’s allocated or not… On Windows: https://searchfox.org/mozilla-central/source/nsprpub/pr/src/md/windows/w95thred.c#151 the thread is created with STACK_SIZE_PARAM_IS_A_RESERVATION flag set. This will allocate the memory immediately. The saving I was mentioning earlier isn’t just due to media decoder threadpool thread stack no longer needing to be that big, but that all other threadpools can be reduced too. Threadpools aren’t used only when playing a video/audio file. Anyway, this needs further inspection… we’ll know soon :) I do hope that the 100 process figures scenario that was given is a worse case scenario though... JY
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
