<div dir="ltr">The bug to watch is bug 989373. We currently merge all JSMs into a single compartment on b2g (something I'd love to change), and turning that behavior off gives us a hit of about 11MiB. We'd still like to figure out how to fix that, but it's a ways off.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 3, 2015 at 9:00 AM, Gijs Kruitbosch <span dir="ltr"><<a href="mailto:gijskruitbosch@gmail.com" target="_blank">gijskruitbosch@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 03/04/2015 16:35, Dirkjan Ochtman wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, Apr 3, 2015 at 5:29 PM, Gijs Kruitbosch<br>
<<a href="mailto:gijskruitbosch@gmail.com" target="_blank">gijskruitbosch@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
AIUI, jsms are our next-best alternative, but using a lot of them has<br>
serious performance downsides (and will also require a bunch of refactoring<br>
for the included scripts).<br>
</blockquote>
We already import ~50 JSMs into browser.js. Converting 21 #include files to<br>
JSMs will be annoying, but I doubt it will have any significant effect on<br>
performance. We'll use a little more memory, but the code will be loaded<br>
more lazily in most cases. It's worth measuring though.<br>
<br>
There are bugs on file to save even using 1 extra JSM (<br>
<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=986503" target="_blank">https://bugzilla.mozilla.org/<u></u>show_bug.cgi?id=986503</a> ) so 21 extra JSMs does<br>
not sound nice.<br>
</blockquote>
That bug is a year old. Is the performance hit/memory consumption<br>
still unchanged?<br>
</blockquote>
<br>
I don't know, but I would be surprised if it changed a lot. Bobby Holley or Nicholas Nethercote (who's on PTO, IIRC) might know more?<br>
<br>
I'll also (again) point out that the refactoring required for moving per-window code into a JSM will be non-trivial. I'm not sure why we would choose it over either Gavin or my suggestion.<span class="HOEnZb"><font color="#888888"><br>
<br>
~ Gijs<br>
</font></span></blockquote></div><br></div>