> On Oct 5, 2015, at 4:53 PM, Dietrich Ayala <[email protected]> wrote: > > +1 to the frog metaphor. > > History has shown it's *incredibly* hard to claw back from performance > regressions. And every moment spent doing so is done *at the cost* of exactly > the type of work Chris described - work that actually moves the project > *forward*. > > I strongly disagree with any acceptance of any performance regression for any > reason except emergency security patches. Only a zero tolerance policy for > perf regressions will result in performant software in such a large and > complex project. > > If you have a tension between perf and features, then it's time to cut the > slow features, or get some more time. >
I feel like most of our apps are severely lacking in the features department already. It would be insane if we expect to be able to add new features to our apps and have our perf numbers remain exactly where they’re at. I’m not saying the sky should be the limit for startup time/memory usage, but we should expect at least *some* increase when new functionality is added. Now, in most cases, new features can be added without affecting the numbers at all, but there are still times when this is simply not possible. > The polish/bugs problems mentioned is fixed by landing fewer bugs (a culture > of detailed automated tests and a project-wide love and acceptance of > backouts), not by accepting perf regressions. > > Also, I recommend not using any subjective measure to compare app startup > times across different platforms. We used tools to do this in the past. > > (My first patch ever, in 2006, regressed Firefox startup time and I spent a > few days on the hook... until my feature could land with no startup hit. Can > you tell it had an impact on me :D) > > On Mon, Oct 5, 2015 at 5:19 PM Fabrice Desré <[email protected] > <mailto:[email protected]>> wrote: > On 10/05/2015 01:46 AM, Christopher Lord wrote: > > I'll preface what I say with the hopefully obvious statement that we > > should always aim for everything to be better. That said, however, I'd > > take a 2mb memory regression and a half-second startup time regression > > if it meant the app was polished and performed well. > > Some apps regressed by way more than 2MB. And also, beware of the > boiling frog. > > > Have you guys used an Android phone recently? Their startup time for > > apps is generally atrocious compared to ours (even on high-end devices) > > - we shouldn't drop the ball, but it's not where we compare badly. Given > > we aren't targeting 256mb devices anymore, I'd gladly have all our apps > > use double the memory they did in 2.2 if it meant we had a consistent > > 60Hz update, consistent transitions and snappy response. > > That's not what I see on a Nexus 4 running CM 12 and on a z3c running L. > They are both super fast and snappy when launching the default apps. > Still better than us on the same hardware. > > Fabrice > -- > Fabrice Desré > b2g team > Mozilla Corporation > _______________________________________________ > dev-fxos mailing list > [email protected] <mailto:[email protected]> > https://lists.mozilla.org/listinfo/dev-fxos > <https://lists.mozilla.org/listinfo/dev-fxos> > _______________________________________________ > dev-fxos mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-fxos
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
