On Feb 22, 2014, at 1:12 PM, David Rajchenbach-Teller <dtel...@mozilla.com> wrote:
> So, I'm wondering how much effort we should put in reducing the number > of ChromeWorkers. On Desktop, we have a PageThumbsWorker and a > SessionWorker, which are both useful but not strictly necessary. I seem > to remember that they each take 1Mb+ of RAM. > > On all platforms, we have the OS.File ChromeWorker, which also takes > 1Mb+ RAM. We could completely get rid of it, but that might be 1+ year > of work. Note that B2G deactivates this ChromeWorker in children > processes after a few seconds. Even on FFOS we can easily afford 1 MB for a temporary task. Firing up a ChromeWorker to do some IO is not a problem. Keeping it around when idle is probably a bad idea on FFOS and desktop. We should continue to use JS in Chrome where it makes sense. Its often easier and faster to write some functionality in JS (and sometimes also safer), and it tends to be more compact when we ship it. In addition to purging caches and stopping idle workers the JS team is also working on making workers (and JS) more memory efficient in general. Naveed might want to chime in here. Happy memory saving. Andreas > > Cheers, > David > > On 2/21/14 10:38 PM, Nicholas Nethercote wrote: >> Greetings, >> >> We now live in a memory-constrained world. By "we", I mean anyone >> working on Mozilla platform code. When desktop Firefox was our only >> product, this wasn't especially true -- bad leaks and the like were a >> problem, sure, but ordinary usage wasn't much of an issue. But now >> with Firefox on Android and particularly Firefox OS, it is most >> definitely true. >> >> In particular, work is currently underway to get Firefox OS working on >> devices that only have 128 MiB of RAM. The codename for these devices >> is Tarako (https://wiki.mozilla.org/FirefoxOS/Tarako). In case it's >> not obvious, the memory situation on these devices is *tight*. >> >> Optimizations that wouldn't have been worthwhile in the desktop-only >> days are now worthwhile. For example, an optimization that saves 100 >> KiB of memory per process is pretty worthwhile for Firefox OS. On a >> phone, memory consumption can be the difference between something >> working and something not working in a much more clear-cut way than is >> typical on desktop. >> >> Conversely, landing new features that use extra memory need to be >> considered carefully. If you're planning a new feature and it will >> "only" use a few MiB on Firefox OS, think again. We probably cannot >> afford it. >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=975367 is the bug that >> motivated me to write this email, but I'm also reminded of Firefox 4, >> which was a release with very high memory consumption partly because >> several groups independently made decisions that using extra memory >> was ok for a particular sub-system and the combined effect was bad. >> >> We live in a memory-constrained world. >> >> Nick >> _______________________________________________ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform >> > > > -- > David Rajchenbach-Teller, PhD > Performance Team, Mozilla > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
