Right, this is what I meant by “Is it worth having this as a constant/preference”. Preference would be nice, but may be more involved as I’m not sure if these values would be used in places before the preference system has had a chance to be initialized... -- - Milan
On Jul 31, 2014, at 23:31 , Kevin Hu <[email protected]> wrote: > 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
