Another thing is, do we really want to have such criteria in codes as a magic number[1]?
https://github.com/mozilla-b2g/gaia/blob/be5fc7f8d2bb6f6ad61294a6e2219827b9930901/apps/system/js/keyboard_manager.js#L421-L429 if (this.isOutOfProcessEnabled && (!isCertifiedApp || this.totalMemory >= 512)) { console.log('=== Enable keyboard: ' + layout.origin + ' run as OOP ==='); keyboard.setAttribute('remote', 'true'); keyboard.setAttribute('ignoreuserfocus', 'true'); } No matter what criteria we will use, I strongly suggest to replace this magic number with some reasonable variables / functions or any other way. It would be easier for us to change the criteria without modifying lots of codes in different places. [1] http://en.wikipedia.org/wiki/Magic_number_%28programming%29 Thanks. Kevin Hu On Aug 1, 2014, at 4:37 AM, Lucas Adamski wrote: > My concern is not that we’ll now have two, but that we already have 4 or 5 > that are pretty random. So we’re better off having two (<256 and <512) than > an undefined number (<=128, <256, <=256, <273, <300, <319, <512 etc) that > often regress functionality in unpredictable ways. > Lucas. > > So I think the right question is are you trying to solve a Tarako (128MB) > problem or a 256MB problem, and pick the corresponding branch (<256, <512). > Lucas. > > On Jul 31, 2014, at 11:52 AM, Milan Sreckovic <[email protected]> wrote: > >> But it already does, right? There are two examples shown below where we >> treat <512mb as a special case. There is already piece of Gecko code that >> treats <=256mb as a special case. I don’t like it either, but I’d at least >> like all the things we don’t like to be consistent. What you guys are >> talking about below is awesome, but it either comes down to setting a >> preference specific to each device, or some run time heuristic we don’t >> already have. In the meantime, people running with 273mb Flames are treated >> by Gecko as “high memory” devices, since the system memory is > 256mb. >> -- >> - Milan >> >> On Jul 31, 2014, at 14:17 , James Ho <[email protected]> wrote: >> >>> I don't like a simple 256/512 number to be only factor that differentiates >>> normal/low-mem devices. Can somebody come out a more realistic equation for >>> that? A few factors I can call out are, screen resolution, BSP/driver >>> overhead such as modem/drivers, etc. Also, we need a tool to measure the >>> memory usage, we can probably take the number we get from MTBF test as the >>> maximum reasonable memory we need for b2g itself alone. >>> >>> -- >>> James Ho >>> Senior Director of Mobile Devices >>> Mozilla Corporation >>> >>> On Jul 31, 2014, at 10:18 AM, Milan Sreckovic <[email protected]> >>> wrote: >>> >>>> >>>> So. Is this “official"? There is at least one place in Gecko that we can >>>> change from “low memory is <= 256” to “low memory is < 512”, but I don’t >>>> really want to do it unless we’re all agreeing to this. Any code in Gaia >>>> that is currently doing special things with other numbers will stop, and >>>> we’ll just look at < 512mb from now on? >>>> >>>> Is it worth having this as a constant/preference? >>>> >>>> -- >>>> - Milan >>>> >>>> On Jul 28, 2014, at 23:20 , Tim Chien <[email protected]> wrote: >>>> >>>>> Input management copy the same number (from the same patch) and >>>>> running keyboard inproc when memory is < 512mb. >>>>> >>>>> https://github.com/mozilla-b2g/gaia/blob/be5fc7f8d2bb6f6ad61294a6e2219827b9930901/apps/system/js/keyboard_manager.js#L421-L429 >>>>> >>>>> On Tue, Jul 29, 2014 at 6:34 AM, Kevin Grandon <[email protected]> >>>>> wrote: >>>>>> Sounds good to me. This is actually exactly what we do for the home >>>>>> screen. We have two different profiles, one with 'high' capabilities, >>>>>> and one with 'low'. Low capability devices are defined with anything >>>>>> less than 512mb of memory. >>>>>> >>>>>> https://github.com/mozilla-b2g/gaia/blob/e13f1f667a49160c3fa3eab89e189910c46b04dc/apps/verticalhome/js/configurator.js#L172 >>>>>> >>>>>> Best, >>>>>> Kevin >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: "Lucas Adamski" <[email protected]> >>>>>> To: "dev-b2g" <[email protected]>, "dev-gaia" >>>>>> <[email protected]> >>>>>> Sent: Monday, July 28, 2014 3:26:58 PM >>>>>> Subject: Low-memory code paths >>>>>> >>>>>> Hi all, >>>>>> >>>>>> In trying to address performance in memory constrained devices, a number >>>>>> of features have been implemented to conserve memory. The problem is >>>>>> these are kicking in at various memory thresholds (256MB, 300MB, etc). >>>>>> >>>>>> This means we see inconsistent behavior when testing Flame in configs >>>>>> like 273MB and 319MB, where memory usage actually regresses with the >>>>>> addition memory being provided. >>>>>> >>>>>> Given the only RAM amounts we’re planning on shipping are in a geometric >>>>>> sequence, we should instead treat any memory amount < 512MB as a memory >>>>>> constrained devices (a further threshold may make sense < 256MB for >>>>>> Tarako). >>>>>> >>>>>> Thoughts, concerns, discussion? >>>>>> Lucas. >>>>>> _______________________________________________ >>>>>> dev-gaia mailing list >>>>>> [email protected] >>>>>> https://lists.mozilla.org/listinfo/dev-gaia >>>>>> _______________________________________________ >>>>>> dev-gaia mailing list >>>>>> [email protected] >>>>>> https://lists.mozilla.org/listinfo/dev-gaia >>>>> >>>>> >>>>> >>>>> -- >>>>> Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox >>>>> OS, Mozilla Corp. (Taiwan) >>>>> _______________________________________________ >>>>> dev-b2g mailing list >>>>> [email protected] >>>>> https://lists.mozilla.org/listinfo/dev-b2g >>>> >>>> _______________________________________________ >>>> dev-gaia mailing list >>>> [email protected] >>>> https://lists.mozilla.org/listinfo/dev-gaia >>> >> > > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
