Performance-related preferences
Hello developers, A couple months ago, Andreas Bovens and I scoured AMO and the Web looking for extensions and articles that offered preferences tweaks in the name of performance. Our hope was to put some of these tweaks through user testing to see if they made any difference in Firefox performance (actual or perceived.) Unfortunately, most of those extensions and articles were junk and often included tweaks to prefs that don't even exist any more. Today I'm hoping you all can help by taking a look over your area of code for any preferences that might impact actual or perceived performance and checking to see if they are still good values for today's browser and today's web. It's probably especially valuable to think about pref values that were set a long time ago. If you have preferences where some science (user studies) would help identify the most appropriate value, I can help with that. Otherwise, if you see a value that's no longer ideal, feel free to update it without further ado. For an example of the kind of pref change that can have real user impact, see https://bugzilla.mozilla.org/show_bug.cgi?id=1283302 Thanks for your time, - Asa ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can gecko be used as a Window manager in Linux CLI as it is used Firefox OS?
On 12/6/14, 3:00 PM, Ankit ladhania wrote: I was thinking of using building a desktop environment that was build using HTML, CSS and JavaScript. I have read about Firefox OS and i know that Gecko is used as a Windows Manager in it. So i want to use it to make DE for my desktop. Does this kind of project already exists ? I can use some clarification in it as i'm confused about how will gecko sit on top of the kernel and how will i program my DE(Desktop Environment). It will be really helpful if some link regarding the same is provided. I recommend asking this question in mozilla.dev.b2g where this work has been done for phones and tablets. There's no reason I can think of that would prevent you from using Gecko+Gaia as a starting point for a PC experience. - A ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: GGC (generational garbage collection) has landed for B2G
On 9/16/14, 12:45 PM, Steve Fink wrote: GGC was enabled yesterday (2014-Sep-15) on b2g-inbound with bug 1020751. It has not yet been merged into mozilla-central, but I expect it will be soon. GGC is already on desktop Firefox, and in fact just shipped with Firefox 32. Keep an eye out for regressions on FxOS. Or improvements, for that matter -- we'd be interested in any real-world workloads that see significant changes. What kind of regressions should we be on the lookout for and in what situations? Performance? Jank? Stability? - A ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Blink removing the concept of user styles?
How much simpler could our style code be if we followed this path? What do the standards and other browser vendors say about this? Horrible idea? Great idea? Mixed? This is in preparation for simplifying the Blink style resolution code by removing the concept of user styles. https://src.chromium.org/viewvc/chrome?revision=234007view=revision - A ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removal of native notification systems on desktop platforms
On 10/12/2013 5:50 AM, Philip Chee wrote: Um, what? libnotify was removed because the developer was too lazy to google for the docs? Phil, you've been in the community long enough to know that this isn't appropriate participation. Insulting other contributors like this is not acceptable and won't be tolerated. - A ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: reminder: content processes (e10s) are now used by desktop Firefox
On 8/5/2013 9:30 AM, Robert Kaiser wrote: Justin Lebar schrieb: It's a lot better than the page a) playing audio, b) spinning your cpu, or a) pwning you. True. Still, if this is a problem (there /are/ a lot of websites which are just one big flash object), I wonder if we could detect it. Yes, I worry about those pages that are one big Flash object, or about pages which have a video as the centerpiece or such. We also get worse thumbnails than before on pages that are basically just a big login screen when you aren't actually logged in. It's pretty hard to figure out the right thing to do in cases like that, I guess (esp. on the well, but private info can't be shown front). Robert Kaiser Private info can't be shown is not a hard requirement here -- at least that's not the position of the Product or Privacy teams. The issue we're solving for here is over-the-shoulder privacy and we've used a pretty big hammer that we may want to back off of some. We should evaluate, possibly through telemetry or FHR, how many users are seeing the e10s thumbnails and if that number is high, I think we'll want to change the criteria for when we go to the e10s thumbnails. - A ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: reminder: content processes (e10s) are now used by desktop Firefox
On 8/2/2013 1:52 PM, Jeff Gilbert wrote: It's certainly worrying given the number of security- and privacy-related addons people rely on working. Seeing ads in thumbnails is relatively harmless (if disconcerting), but if someone is relying on an addon for important security or privacy reasons, and we auto-updated them and bypassed their protections, that's more serious. -Jeff I think it's up to add-ons to keep up with Firefox, not the other way around. We give them no less than 3 months to adjust to our changes. Is that not enough time? - A ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: running tests in HiDPI mode on the build machines
On 7/8/2013 8:18 PM, Cameron McCormack wrote: I think it's time we considered having tests running on the build machines in HiDPI mode so that we can catch regressions that only manifest themselves in high resolution configurations. We have at least three platforms we're targeting where this is going to be useful: Firefox on Retina MBPs, and Firefox for Metro and Firefox for Android on high res devices. Please add to this list Windows Firefox desktop. Given the capacity constraints we have in the build farm, would it be sufficient to run HiDPI tests on Linux or Linux64, where we can easily spin up more AWS machines? Testing the only Firefox platform that isn't on the above list? Wouldn't it be smarter to test on Windows 7 or some combination of Windows machines where almost all of our users are? - A ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using a pre-processing flag to auto-disable features in later Beta versions
On 4/19/2013 3:17 PM, Daniel Holbert wrote: Would this mean that Beta-channel users would see some features appear on release-day, and then disappear a couple weeks later, and then those same features (plus maybe some new ones) would suddenly reappear on the next release day, and then potentially disappear again? (etc) This seems like it could be a bit unsettling frustrating for those users, unless I'm misunderstanding. If we're planning up-front to switch something off before it hits release, I think it's saner to do it at a channel-boundary (as we did in e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=814530 ). That way, a user on a given channel will have a consistent experience. ~Daniel That would be great -- if we had a significantly larger Aurora population. Right now, the only way to get anything close to decent did we break the web testing is on our Beta channel. - A On 04/18/2013 01:03 PM, Lukas Blakk wrote: Hello, I'm following up on an action from our Firefox 20 Post-Mortem where it was discussed that it would be helpful to have a way to pref on a set of features that want to be in early Beta builds to garner feedback and audience reach but should not ship since they are not ready for public consumption. Briefly reaching out on #developers identified that we could use a pre-processing flag in mozconfigs for early betas, something like #ifdef EARLY_BETA_ONLY_FEATURE in which case it seems to me the actions needed would be: * Create and publicize to engineering product teams the location for listing feature prefs that need enabling in early beta, but should not ship * Create the EARLY_BETA_ONLY_FEATURE flag and make sure it enables those prefs accordingly until we no longer include them in later beta mozconfigs * Releng automation to switch/edit mozconfigs for earlier betas to check for this flag Thoughts? Feedback? People willing to take on any of these items? I'll file bugs on them soon once we've hashed out the best way to do this. Cheers, Lukas *-*-*-*-*-* Release Manager, Mozillian mozillians.org/lsblakk ___ 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
Re: Using a pre-processing flag to auto-disable features in later Beta versions
On 4/19/2013 4:04 PM, Robert O'Callahan wrote: On Sat, Apr 20, 2013 at 10:34 AM, Asa Dotzler a...@mozilla.com wrote: That would be great -- if we had a significantly larger Aurora population.. Right now, the only way to get anything close to decent did we break the web testing is on our Beta channel. I think Daniel was concerned about user-visible features (and I agree with that concern). If we're only going to use this flag for does this break the Web tests, where we expect/hope users will not notice, that sounds fine to me, as long as we stick to that rule. Rob I don't think it's that black and white. PDF.js and our new Cookie policy are both user facing features and web compat concerns that need a crap ton of compat testing. Shumway will be the same. So may some security features like mixed content blocking, plug-in click-to-play, etc. - A ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Preparing for the next windows PGO build memory exhaustion
On 4/13/2013 1:59 AM, Mike Hommey wrote: On Sat, Apr 13, 2013 at 10:28:47AM +0200, Mike Hommey wrote: I think we need to start thinking how to make PGO opt-in instead of opt-out, while keeping performance where it is now. I have a really basic question. Is PGO's performance gains something users are actually going to notice or are we mostly talking about synthetic benchmark pissing contests here? What's PGO's impact on start-up time or new window time or the loading of a Twitter or Facebook web page? I've also seen over the years that we have a really difficult time diagnosing and fixing some high profile crashes because of PGO and if we can eliminate those or make them easier to diagnose and fix and all it costs us is a some points on Sunspider, I'm wondering if it doesn't make sense to just drop PGO and focus on finding performance wins elsewhere. - A ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Increase in memory utilization on Mac OSX 10.7+ due to history swipe animations
On 2/12/2013 3:08 PM, Ed Morley wrote: On 12 February 2013 22:11:12, Stephen Pohl wrote: I wanted to give a heads up that we're in the process of finalizing the patch for bug 678392 which will give us history swipe animations on Mac OSX 10.7+. Since we will be taking snapshots of the 20 most-recently visited pages, this will undoubtedly lead to an increase in memory utilization on these platforms. To save everyone having to look at the graph - the initial landing showed a consistent 20% regression in trace malloc maxheap. If this were a 1-5% regression, then I think it would be worth discussing the trade-off. At 20%, I really don't see how we can take this, sorry! :-( Ed I don't see how we can *not* take this. Of course it's going to mean using more memory. If it doesn't leak, and it doesn't put us over some magic limit where a significant portion of our users end up paging or something like that, then I don't see how we can reject it. Without context, 1-5% or 20% growth are just meaningless numbers. The context here is not some accidental regression or a feature doing something horribly wrong with memory. This is simply a memory-expensive feature and it's a feature we *must* land. I'm all for smart people looking for ways to get this memory usage as low as it can be without undermining the value of the feature, but if we cannot find those wins, we should land this as it is. - A ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Integrating ICU into Mozilla build
On 12/3/2012 2:39 PM, Norbert Lindenberg wrote: Well, the first question is what size increase would be acceptable given the benefits that ICU provides. I don't understand what benefits this actually provides. How are users' online lives improved by this change, either today or in the future? Adding to the download size costs us in user acquisition so we cannot be OK with taking on megabytes of additional download size for features of questionable value. - A ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed policy change: reusability of tests by other browsers
On 8/21/2012 6:34 AM, Gervase Markham wrote: On 20/08/12 18:25, Asa Dotzler wrote: Can you say more about this? Are you saying it's Mozilla's responsibility to put Mozilla resources into solving problems for Opera? I'm not sure I understand this assertion. I think he's arguing that a belief in user choice could well translate into doing things in a way which helps (or at least does not hinder) other browsers. How do you think our belief in user choice should translate into our attitude to other browsers using our work? Gerv I don't believe our belief in user choice should cause us to spend extra resources helping other browsers if those extra resources slow us down in our attempts to be effective competitors with those other browsers. - A ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed policy change: reusability of tests by other browsers
On 8/21/2012 10:32 AM, L. David Baron wrote: On Tuesday 2012-08-21 09:43 -0700, Asa Dotzler wrote: On 8/21/2012 6:34 AM, Gervase Markham wrote: On 20/08/12 18:25, Asa Dotzler wrote: Can you say more about this? Are you saying it's Mozilla's responsibility to put Mozilla resources into solving problems for Opera? I'm not sure I understand this assertion. I think he's arguing that a belief in user choice could well translate into doing things in a way which helps (or at least does not hinder) other browsers. How do you think our belief in user choice should translate into our attitude to other browsers using our work? Gerv I don't believe our belief in user choice should cause us to spend extra resources helping other browsers if those extra resources slow us down in our attempts to be effective competitors with those other browsers. In the long term, I think sharing tests with other browsers can be a speed-up, both for us and for the Web platform as a whole, since we: (a) have to spend less time changing our behavior when browsers are found to disagree with each other (something that's often more work when the problems are discovered later) (b) get to a more interoperable platform faster, which helps the Web compete against non-Web platforms David, I can certainly see the value there. That is, IMO, quite different from the position I was responding to, Aryeh Gregor suggestion that our mission compells us to to put special effort into making things as easy as possible for smaller browsers. - A ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed policy change: reusability of tests by other browsers
On 8/19/2012 1:41 AM, Aryeh Gregor wrote: Anyway, one major goal of an open web is that users should have as many choices as possible for web browsers. That means we need to put special effort into making things as easy as possible for smaller browsers. So if Opera will definitely use our tests and other browsers might or might not, I think that's a good reason to go ahead. Can you say more about this? Are you saying it's Mozilla's responsibility to put Mozilla resources into solving problems for Opera? I'm not sure I understand this assertion. - A ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
