Android/ARM Firefox Perforamance: where we are and where to go |
David Mandelin |
8/22/11 6:18 PM |
(Oops--posted this to mozilla.dev.performance and dev-planning@lists by mistake--I meant to post in dev.planning both ways. Please add the list to followups to keep conversation together.) I've been thinking a bit about what can do, and what we need to do, for Firefox performance on mobile devices. This is really just a start, but I think it points the way for the performance efforts we have to make to make Firefox just as great on Android/ARM as it is on desktop. I give an evaluation of performance today, recommendations for top performance goals, some big changes we might need, and last, a draft plan, really just a sketch, of the way forward. Dave 0. Summary If you have a powerful device, Firefox performance is in many ways pretty good. But UI responsiveness and memory usage seem to be in pretty bad shape, although they are hard to measure. So we need to get better measurements and start improving performance in those areas, today. If you don't have a powerful device, things are worse. General improvements--especially in memory, the prime suspect--should help us there. But I think we also need to get the message out about what kinds of hardware give a good Firefox experience, so that we don't have people trying it on devices where it's just not good yet, and deciding that we're no good. A. The State of Performance on Firefox for Android Unless specified otherwise, all numbers for Firefox are for Firefox 6 on my Atrix. A1. Footprint: Acceptable. Installed footprint is 14 MB. Opera Mobile is 12 MB, so it seems we are not too bad. There are a lot of complaints about this in the App Store, but I don't think this is going to make or break us. Taras told me we could shave off a few MB by eliminating dead code and making some toolchain tweaks. I don't know how much effort would be involved. A2. Startup: Not Good. Startup time is 5s. Opera is about the same. Stock is 1.5s. There are a lot of complaints about this in the App Store. For my personal use, I don't care too much, because I only start the browser once per crash. But it probably matters at least somewhat. I had assumed that stock was faster because it used special tricks to get pre-started, and so there was not much we could do (taking Opera's similar score as evidence we are about as good as we can be). But Taras says that we should be able to get down to 2s on his Galaxy S. He listed these items as wasted time in startup: - 0.5s XUL reflows - 0.5s sqlite IO (150-1000ms, avg 500) - ~0.5s linker badness (needs linker improvements) - unknown needlessly parsing XML, CSS, etc. I also tested clicking the app icon when the browser is already open (maybe this is "warm startup"--not sure what the right term is). I found that stock is the fastest, with almost no delay, Opera Mobile has a delay, and Firefox is clearly the slowest. So that area needs help too. A3. Memory Usage: Unknown, probably bad. Memory statistics on Android are hard to understand. When I wrote the first draft, I just checked the browser as it happened to be on my phone, with a few tabs open. 'Task Manager' showed 'RAM: 64 MB', but about:memory showed 'resident' (which I believe is supposed to give the amount of memory the process has currently in RAM) of about 80 MB for the main process and 40 MB for the content process. I also see these problems with our memory reporting: - 'resident' tends to be about 2x 'heap-committed'. On desktop the numbers are about equal. So either the reporter is wrong or these numbers mean something else on Android. - 30-40% of explicit allocations are 'unclassified'. Getting better information here (higher quality data and/or better understanding of it) should be a high priority. For now, based on what information we do have, memory usage on Android seems pretty bad. Some indirect evidence: I get a lot of crashes, which I think might be OOMs. Also, my phone has 1 GB RAM while Taras's has 512 MB, and I seem to get better perceived performance, which points to memory limits. (Taras says other apps, including the music player, get tossed out of RAM when he uses Firefox.) Finally, comments in the App Store suggest that on wimpy devices, Firefox is much slower than other browsers, which appears not to be the case on powerful devices. Looking at the direct measurements, both Taras and I think that ~80 MB for the chrome part of the browser is unacceptable. Taras says he thinks 20 MB (of which 10 MB is for JVM) would be a good target. He also says that XUL seems to be responsible for about half the memory we do use. A4. Pageload: Acceptable to Good, but maybe not for everyone. I tested Firefox against Opera Mobile and stock by loading 8 pages and timing the interval between 'click enter' and 'pageload animation stops' with a stopwatch. Firefox beat both of them on 6 of 8 tests (but not the same 6). stock was faster on engadget and a bit faster on nytimes, and Opera was faster on walmart and a hair faster on loading a techcrunch article. Taras seems less sanguine about this--I think his device's smaller RAM may be the difference. We should get more information about how pageload looks on different devices and device classes. Taras also said that Alon Zakai told him IPC overhead between main and content processes is hurting us here. A5. JavaScript: Acceptable to Good. Current benchmark results: SunSpider-0.9.1 V8-v6 Firefox 2031 306 Opera Mobile 2254 318 Stock 2.3 4219 336 We're the best on SunSpider, beating stock by over 2x. We're slower on V8 but still within 10% of both competitors. Current projects (IonMonkey, Generational GC) should give us a big boost on V8 on all platforms, including Android/ARM. Mainly, we need to get good support for ARM codegen in IonMonkey from the beginning, and see if we need any Android-specific GC tuning. A6. Panning/Zooming: Bad/OK. I get lots of checkerboarding if I pan quickly, moreso than in other mobile browsers. Zooming is OK for me, but I do see complaints about it in the app store, and the graphics quality during zooming is lower than stock, so maybe we are using that to compensate for lower underlying performance. A7. UI Responsiveness: Unknown, probably bad. The UI often seems sluggish, and I hear this a lot from other people. But I tried a simple eyeball test of various UI clicks (e.g., clicking the location bar) against Opera Mobile and stock, and it seems to me that the time from 'click' to 'thing I wanted is visible and ready to use' is usually about the same, with two exceptions: - the first time I use a feature (e.g., add-ons manager), it is extra slow - sometimes there is just a long delay So there are a couple of concrete problems, but otherwise it seems OK. But users still seem to perceive Firefox to be unresponsive, and that may be the bigger problem: - Firefox is unique among mobile browsers in not having a progress bar. - I notice that Opera Mobile and stock animate other things: e.g., if I click the options button (the O button on Opera), the option panel smoothly slides up from the bottom, and the sliding starts instantly on the click. But in Firefox, nothing happens for a brief interval, then the panel appears. B. Performance Goals I propose these broad goals and priorities for mobile performance: Top Goals (start immediately on all of them): B1. Fully understand memory usage. This means: know what all the different memory metrics mean, make sure they all fit together, and understand how different features of Firefox's architecture and design affect memory usage. B2. Reduce memory usage, a lot. We don't quite know this is a valid goal at this point, but if it's as bad as it looks, it can't wait until B1 is done. B3. Improve perceived performance. This can start with a progress bar for pageload and some more animation. Presumably someone else knows a lot more about this. B4. Fix panning performance. I've heard it used to be worse, so someone out there probably knows something about this. Secondary Goals: B5. Improve startup time. B6. Improve pageload time. B7. Improve JavaScript performance. B8. Reduce footprint. C. Crazy Ideas The first two aren't really crazy--I think they need to be taken seriously. The third is more of a research idea and a long-term bet, but I still want to mention it here. C1. Non-XUL Front End Architecture. Taras found that XUL about doubles our memory usage. That's pretty bad. It also likely slows things down. I think we should seriously consider creating a new, non-XUL front end for Android. A key question is, "Can we ever have competitive performance with a XUL-based front-end". If the answer is "no", then we must start now on a new front end. If the answer is "maybe", then we should probably still start now on a new front end. C2. Single-Process Architecture. We apparently have evidence that IPC is slowing us down. I don't have any measurements there, so I don't know much about the problem. But again, we need to think hard about whether the current multiprocess architecture is going to get us to where we want to be (taking into account any predicted improvements in Android IPC) and if it won't, it's time to do something about that. C3. Mobile Performance Research. The discussion in this document so far is focused on closing the gap where we are behind, and incrementally improving performance elsewhere. But we can think bigger on performance, in particular about closing the gap between mobile and desktop. For example, you can use the Netflix queue management page from a tablet or smartphone, but it's painfully slow--*barely* usable. What can we do to make it fully usable? I think we want HTML5 to be the thing, not closed app stacks. We could look into how to make something like the Netflix app in HTML5, but faster. We could look into changes to the standards that make it easier to run fast on mobile. D. Draft Plan Definitely start now: D1. Make about:memory make sense. This means fixing the reporters, understanding what the numbers mean and documenting it, or both. D2. Make mobile memory usage top priority for MemShrink. D3. Make the call on whether to start work on a non-XUL front end. My gut says a new front end is the only way and we should just do it, but I'm not particularly well-informed. Notice that I'm not saying to make the call on whether to *use* the non-XUL front end--we do that only when we have it. We can hedge bets in various ways depending on opportunities and risks. D4. Make the call on going to a single-process architecture. D5. Add a progress bar for pageload. D6. Add animations for UI actions. Other stuff that seems important, and could be started now, but I'm less sure about, or isn't as urgent: D7. Develop tools to visualize latencies (like the timeline views that webdevs get now) to help figure out how to make things faster. Taras says we don't need the general tool, just direct instrumentation as needed. This is probably true, but the tool might still have value. D8. Get oprofile working on Android and teach people how to use it. Taras says that it won't help with latencies. He's probably right. There might still be some use for this, but I'm not sure. D9. Fix panning performance. D10. Dig in on cold startup time. D11. Dig in on "warm startup" time. D12. Add tools to directly expose resource usage in the UI: CPU, memory, network, etc. This way users and devs can see what's happening as the use the product, and find opportunities to improve. Think tools like Framerate monitor. D13. Collect data on pageload times: stats on times in the wild, and comparisons with other browsers. D14. Dig in pageload time: measure the latencies and figure out how to make it faster on pages of interest. D15. Dig in on long UI pauses. D16. Spin up research on mobile performance. --end _______________________________________________ dev-planning mailing list dev-pl...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-planning |
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Matt Brubeck |
8/22/11 7:47 PM |
On 08/22/2011 06:18 PM, David Mandelin wrote: > Taras found that XUL about doubles our memory usage. That's pretty bad. > It also likely slows things down. I think we should seriously consider > creating a new, non-XUL front end for Android. This is not strictly true. Taras found that creating a barebones <browser> with no chrome at all used about half the memory compared to regular Fennec chrome. So it's not necessarily "XUL" that is bloating memory, but a combination everything loaded by Fennec chrome. This includes XPCOM components, JS modules, native libraries, and more. https://bugzilla.mozilla.org/show_bug.cgi?id=632177 https://bugzilla.mozilla.org/show_bug.cgi?id=618912 Last time I tried (many months ago), I could not replicate Taras's results. Repeating his experiment with the patches in those bugs, I found a much smaller reduction in memory usage, and little or no difference between his barebones XUL chrome and HTML chrome. This was all done before the recent MemShrink and about:memory improvements, so it's definitely worth repeating these experiments now that we can get much more useful data from them. A non-XUL frontend is certainly worth considering. We'd give up much of our current add-on model, but it would open up things like using native Android widgets, which would gain us much better platform integration and UI consistency.
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Boris Zbarsky |
8/22/11 7:50 PM |
On 8/22/11 9:18 PM, David Mandelin wrote: > Looking at the direct measurements, both Taras and I think that ~80 MB > for the chrome part of the browser is unacceptable. Taras says he thinks > 20 MB (of which 10 MB is for JVM) would be a good target. He also says > that XUL seems to be responsible for about half the memory we do use. How many XUL elements do we end up with in the Fennec chrome once all XBL bindings are instantiated? > B1. Fully understand memory usage. This means: know what all the > different memory metrics mean, make sure they all fit together, and > understand how different features of Firefox's architecture and design > affect memory usage. There's been a bunch of progress on about:memory since the Fx6 build you tested, including a lot more stuff being classified now. Worth testing with a nightly. If the 2x gap between 'resident' and 'heap-comitted' is still there in current nightlies, we should try to understand it. > Taras found that XUL about doubles our memory usage. That's pretty bad. > It also likely slows things down. I think we should seriously consider > creating a new, non-XUL front end for Android. We should also consider asking some hard questions like whether the current XUL setup makes sense, esp. for Fennec. In particular, XUL is currently optimized for creating multiple copies of a single XUL document (read: multiple windows) in terms of its memory consumption: it maintains a prototype document and then creates instance documents based on that. The result is that if you only have one window open you use _more_ memory than if we just had a straight-out DOM. Since Fennec always has only one window open, it hits the worst-case for this setup. Do we have any data on how much space the prototype XUL document is using vs the instance document in Fennec? Have we considered prototyping out a front-end that uses XUL _markup_ but uses an HTMLDocument for the actual document? That would avoid the proto document thing going on (though it would lose fastload and the like, of course; I'm primarily interested in the memory usage for the moment). This is all in addition to a possible non-XUL front end. > For example, you can use the Netflix queue management page from a tablet > or smartphone, but it's painfully slow--*barely* usable. What can we do > to make it fully usable? Profile it, for a start? I'd dearly love to see some profile data here, or any howto on android profiling we have around if we have one... -Boris
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Boris Zbarsky |
8/22/11 7:50 PM |
On 8/22/11 9:18 PM, David Mandelin wrote:
> Looking at the direct measurements, both Taras and I think that ~80 MB > for the chrome part of the browser is unacceptable. Taras says he thinks > 20 MB (of which 10 MB is for JVM) would be a good target. He also says > that XUL seems to be responsible for about half the memory we do use. How many XUL elements do we end up with in the Fennec chrome once all XBL bindings are instantiated? > B1. Fully understand memory usage. This means: know what all the > different memory metrics mean, make sure they all fit together, and > understand how different features of Firefox's architecture and design > affect memory usage.
There's been a bunch of progress on about:memory since the Fx6 build you
tested, including a lot more stuff being classified now. Worth testing with a nightly. If the 2x gap between 'resident' and 'heap-comitted' is still there in current nightlies, we should try to understand it. > Taras found that XUL about doubles our memory usage. That's pretty bad. > It also likely slows things down. I think we should seriously consider > creating a new, non-XUL front end for Android.
We should also consider asking some hard questions like whether the
current XUL setup makes sense, esp. for Fennec. In particular, XUL is currently optimized for creating multiple copies of a single XUL document (read: multiple windows) in terms of its memory consumption: it maintains a prototype document and then creates instance documents based on that. The result is that if you only have one window open you use _more_ memory than if we just had a straight-out DOM. Since Fennec always has only one window open, it hits the worst-case for this setup. Do we have any data on how much space the prototype XUL document is using vs the instance document in Fennec? Have we considered prototyping out a front-end that uses XUL _markup_ but uses an HTMLDocument for the actual document? That would avoid the proto document thing going on (though it would lose fastload and the like, of course; I'm primarily interested in the memory usage for the moment). This is all in addition to a possible non-XUL front end. > For example, you can use the Netflix queue management page from a tablet > or smartphone, but it's painfully slow--*barely* usable. What can we do > to make it fully usable?
Profile it, for a start? I'd dearly love to see some profile data here,
or any howto on android profiling we have around if we have one...-Boris
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Jonas Sicking |
8/22/11 7:54 PM |
Note that non-XUL doesn't need to mean non-Gecko. One option is to build a front-end in HTML. I think the HTML code has received a lot more performance love than the XUL code in many areas. / Jonas
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Matt Brubeck |
8/22/11 8:11 PM |
Thanks a lot for this list, by the way. Here are some pointers to existing work for anyone who is curious or who wants to know of places to get started. On 08/22/2011 06:18 PM, David Mandelin wrote:
> Zooming is OK for me, but I do see complaints about it > in the app store, and the graphics quality during zooming is lower > than stock, so maybe we are using that to compensate for lower > underlying performance. We already do high-quality zooming when OpenGL hardware acceleration is enabled. We should also be able to do fast high-quality zooming in software on most devices; the patch to enable that had some problems but they might be fixed soon (or already?) by other graphics changes: https://bugzilla.mozilla.org/show_bug.cgi?id=656797 > the first time I use a feature (e.g., add-ons manager), it is > extra slow We do a lot of aggressive lazy-loading of UI to help start-up time, but this does add latency later on when these features are used. > D4. Make the call on going to a single-process architecture. You can do some experiments by setting browser.tabs.remote=false, though of course we haven't been optimizing for single-process, and also some Fennec features are broken or not implemented in single-process tabs. > D5. Add a progress bar for pageload. We'll soon replace the current 4fps throbber with a much smoother one that is two-state (like desktop Firefox) to provide better perceived smoothness and better feedback on the loading process: https://bugzilla.mozilla.org/show_bug.cgi?id=679927 > D6. Add animations for UI actions. This has long been blocked on making animations smooth enough to be usable on mobile. With some in-review patches to reduce reflows during animation, this is apparently doable now and should land soon. Patches along with lots of history and discussion here: https://bugzilla.mozilla.org/show_bug.cgi?id=524925 > D9. Fix panning performance. This is the focus of a lot of work right now by Heeen, Chris Lord, Oleg Romashin, and others. There are many patches landing or about to land that should improve this. Many patches to fix OpenGL hardware rendering have also just landed or are in review; the graphics team can comment on the expected impact from that. https://wiki.mozilla.org/Fennec/Features/perf has a list of other related bugs and queries. There are a lot of things we've identified as possible improvements but haven't had time to pursue yet. > D13. Collect data on pageload times: stats on times in the wild, and > comparisons with other browsers. We have some crowd-sourced page load benchmarks here, along with a framework for gathering more: https://zippityserver.appspot.com/ The current Zippity page load benchmark uses a fixed list of popular sites (like Talos tp4), but unlike Talos it downloads the sites over the internet from real-world web servers. Ben Stover has also proposed some improvements to perceived page load performance like showing fewer disruptive repaints or checkerboards: https://bugzilla.mozilla.org/show_bug.cgi?id=680126
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Justin Lebar |
8/22/11 8:16 PM |
>> B1. Fully understand memory usage. This means: know what all the >> different memory metrics mean, make sure they all fit together, and >> understand how different features of Firefox's architecture and design >> affect memory usage. > > There's been a bunch of progress on about:memory since the Fx6 build you > tested, including a lot more stuff being classified now. Worth testing > with a nightly. > > If the 2x gap between 'resident' and 'heap-comitted' is still there in > current nightlies, we should try to understand it. heap-committed is basically meaningless except with jemalloc on Windows. This is reflected in its description in the latest about:memory. Bug 674290 should work on Android and should help us understand any gap between resident and heap usage.
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Justin Lebar |
8/22/11 8:16 PM |
>> B1. Fully understand memory usage. This means: know what all the >> different memory metrics mean, make sure they all fit together, and >> understand how different features of Firefox's architecture and design >> affect memory usage. > > There's been a bunch of progress on about:memory since the Fx6 build you > tested, including a lot more stuff being classified now. Worth testing > with a nightly. > > If the 2x gap between 'resident' and 'heap-comitted' is still there in > current nightlies, we should try to understand it. heap-committed is basically meaningless except with jemalloc on Windows. This is reflected in its description in the latest about:memory. Bug 674290 should work on Android and should help us understand any gap between resident and heap usage.
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Matt Brubeck |
8/22/11 8:25 PM |
>> D9. Fix panning performance. One thing that we really need here is a better panning benchmark. It should measure panning in terms of frame rate, "jankiness" (max length pauses or dropped frames), and amount of checkerboard visible when panning at different rates. Our current panning benchmark Tpan measures panning in terms of latency, which is not what we want. Then we could run the improved benchmark on real-world pages with different types of content (images, text, gradients, alpha blending, rounded corners, etc.). I'm also think there are more ways we could improve perceived panning performance, for example replacing checkerboards with a solid background (the same as the content's background, if possible). This seems to be what the Android 3.x browser does.
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Robert O'Callahan |
8/22/11 8:32 PM |
Great write-up! On Tue, Aug 23, 2011 at 1:18 PM, David Mandelin <dman...@mozilla.com>wrote: > - 0.5s XUL reflows > We should be able to fix this in layout. The old XUL flexbox code is pretty crazy but Daniel Holbert has a new implementation of CSS3 flexbox that should be better. It would be helpful if someone imported the Fennec UI into a standalone test page for easy performance analysis. Rob -- "If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us." [1 John 1:8-10]
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
L. David Baron |
8/22/11 9:07 PM |
On Tuesday 2011-08-23 15:32 +1200, Robert O'Callahan wrote: > Great write-up! > > On Tue, Aug 23, 2011 at 1:18 PM, David Mandelin <dman...@mozilla.com>wrote: > > > - 0.5s XUL reflows > > > > We should be able to fix this in layout. The old XUL flexbox code is pretty > crazy but Daniel Holbert has a new implementation of CSS3 flexbox that > should be better. It would be helpful if someone imported the Fennec UI into > a standalone test page for easy performance analysis. I suspect this isn't actually reflow, though. In XUL documents a lot of stuff, including frame construction and style resolution, happens inside of PresShell::InitialReflow. The previous times I've seen reflow accused of being this portion of a profile, it was actually "all the stuff inside PresShell::InitialReflow" being accused. *Lots* of stuff in layout happens lazily, so if you want to break down time spent in style vs. frame construction vs. reflow, you really need to split profiles using a tool like http://mxr.mozilla.org/mozilla-central/source/tools/jprof/split-profile.pl For more details, see my posts on 2010-05-06 to dev.platform in the thread "Startup Timeline - Can you help?" which unfortunately are not archived on google groups as far as I can tell. -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla Corporation http://www.mozilla.com/ 𝄂
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mike Hommey |
8/22/11 10:35 PM |
On Mon, Aug 22, 2011 at 06:18:33PM -0700, David Mandelin wrote: > - 0.5s XUL reflows > - 0.5s sqlite IO (150-1000ms, avg 500) > - ~0.5s linker badness (needs linker improvements)
That's actually more like 0.8 to 1s when you don't have enough space on your device, and ~0.3s when you do. Though the first start is then abysmal, as writing the decompressed files usually takes more than 2s. We should delay that decompression. Speaking of the first start, creating the profile is also taking a whole lot of time, and really doesn't help making a first good impression. > - unknown needlessly parsing XML, CSS, etc.
- 0.2 to 0.3s between the process starting and our code actually starting. :( We should aim at having the UI show up under 1.5s, which is optimistic, but I think is possible. One of the problems is that we do lot of things during startup that could just wait after the UI, or a part of it, is displayed to the user. I think Sqlite I/O happens before the UI is displayed, for example. We could delay NSS loading, too, as well as a whole lot of things we don't use during startup. These would not only help mobile startup, but desktop, too. Mike
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Axel Hecht |
8/23/11 4:13 AM |
On 23.08.11 03:18, David Mandelin wrote: > 0. Summary > > If you have a powerful device, Firefox performance is in many ways > pretty good. But UI responsiveness and memory usage seem to be in pretty > bad shape, although they are hard to measure. So we need to get better > measurements and start improving performance in those areas, today. > > If you don't have a powerful device, things are worse. General > improvements--especially in memory, the prime suspect--should help us > there. But I think we also need to get the message out about what kinds > of hardware give a good Firefox experience, so that we don't have people > trying it on devices where it's just not good yet, and deciding that > we're no good. I'd like to point back to Dietrich's post about Android devices in Asia and Africa here. Excluding some range of devices could effectively exclude complete markets. <...> > C1. Non-XUL Front End Architecture. > > Taras found that XUL about doubles our memory usage. That's pretty bad. > It also likely slows things down. I think we should seriously consider > creating a new, non-XUL front end for Android. > > A key question is, "Can we ever have competitive performance with a > XUL-based front-end". If the answer is "no", then we must start now on a > new front end. If the answer is "maybe", then we should probably still > start now on a new front end.
When doing that experiment, please make sure it'll compare apples to apples. In particular our l10n story on mobile is undergoing changes, aside from the obvious "it should be localizable". We intend to ship language packs only on mobile, which means that the non-xul base technology needs to support that, and also needs to support runtime locale switching in some way. It also means that the interface as is needs to support both LTR and RTL. Unless we completely redefine what a language pack is, at which point the base technology needs to support that, too. Similar challenges are probably coming from a11y, don't know enough, but they're usually in the same bucket as l10n. Axel
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Kyle Huey |
8/23/11 4:26 AM |
Somebody already mentioned this earlier, but I wouldn't call memory usage numbers for Firefox 6 "state-of-the-art". There are a *lot* of improvements in 7 (and more following) ... both in the reporting and in actual consumption. - Kyle
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Ali Juma |
8/23/11 6:50 AM |
On 2011-08-22, at 11:11 PM, Matt Brubeck wrote:
> There are many patches landing or about to land that should improve this. Many patches to fix OpenGL hardware rendering have also just landed or are in review; the graphics team can comment on the expected impact from that. Panning, scrolling, and zooming certainly feel faster with OpenGL hardware rendering; the difference seems most pronounced on larger pages. We'll be doing some profiling over the next couple of weeks, so we'll soon have a more quantitative measure of the impact (and we'll also know whether OpenGL hardware rendering will cost us in other areas like page load time). The current status of OpenGL on Android can be found at https://wiki.mozilla.org/index.php?title=Platform/GFX/GLLayersOnMobile -Ali |
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Ludovic Hirlimann |
8/23/11 7:11 AM |
This looks like the experience I go through > D. Draft Plan > > Definitely start now: > > D1. Make about:memory make sense. This means fixing the reporters, > understanding what the numbers mean and documenting it, or both. > > D2. Make mobile memory usage top priority for MemShrink.
I currently run nightlies and used to use zippity to send data on my phone and how firefox performed on it. Should we try to gather more data thru that extension ? Ludo -- Ludovic Hirlimann MozillaMessaging QA lead https://wiki.mozilla.org/Thunderbird:Testing http://www.spreadthunderbird.com/aff/79/2
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Robert Kaiser |
8/23/11 7:26 AM |
David Mandelin schrieb: > - Firefox is unique among mobile browsers in not having a progress bar.
Firefox on both mobile and desktop does not give a whole lot of feedback of "loading a page", which I have seen to cause confusion for users a number of times when I watched them doing things on the web. > Taras found that XUL about doubles our memory usage. That's pretty bad. > It also likely slows things down. I think we should seriously consider > creating a new, non-XUL front end for Android. 1) We don't have any good support for embedding Gecko in native apps right now, we'd need to build that from scratch - and we would make it impossible to use this frontend on any other mobile system or run Fennec on desktop for testing the way we do now if we go with a Android-native interface. It also would kill a lot of possibilities of add-ons. 2) XUL surely has some overhead we need to work on, though I wonder if it might be better to work on making HTML fit for rendering the UI instead, which would benefit everyone - from web apps to desktop Firefox. > We apparently have evidence that IPC is slowing us down. It should make the UI more responsive, even more on non-single-core devices, but it takes up more memory, which I think is what is killing us mostly on mobile right now. I've seen that Fennec measurements on MeeGo N900 Community Edition jumped to *way* better every time they patched something in the system to not be loaded and therefore leave more memory to applications - as that's a low-memory device, this is very visible there but I think memory pressure being the way largest problem is something that should apply on Android as well. Robert Kaiser -- Note that any statements of mine - no matter how passionate - are never meant to be offensive but very often as food for thought or possible arguments that we as a community should think about. And most of the time, I even appreciate irony and fun! :)
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Robert Kaiser |
8/23/11 7:30 AM |
Jonas Sicking schrieb: > Note that non-XUL doesn't need to mean non-Gecko. One option is to > build a front-end in HTML. I think the HTML code has received a lot > more performance love than the XUL code in many areas.
I think that HTML still needs some love to measure up to XUL in terms of using it for UI, but starting with converting Fennec UI over might be the right thing because it has relatively little UI compared to everything else and improving HTML for the things needed there is probably a good start. Robert Kaiser -- Note that any statements of mine - no matter how passionate - are never meant to be offensive but very often as food for thought or possible arguments that we as a community should think about. And most of the time, I even appreciate irony and fun! :)
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Benjamin Smedberg |
8/23/11 7:54 AM |
On 8/22/2011 9:18 PM, David Mandelin wrote: > > A3. Memory Usage: Unknown, probably bad. > > >
> Getting better information here (higher quality data and/or better > understanding of it) should be a high priority. > > For now, based on what information we do have, memory usage on Android > seems pretty bad. Some indirect evidence: I get a lot of crashes, which > I think might be OOMs. Also, my phone has 1 GB RAM while Taras's has 512 > MB, and I seem to get better perceived performance, which points to > memory limits. (Taras says other apps, including the music player, get > tossed out of RAM when he uses Firefox.) Finally, comments in the App > Store suggest that on wimpy devices, Firefox is much slower than other > browsers, which appears not to be the case on powerful devices. > > Looking at the direct measurements, both Taras and I think that ~80 MB > for the chrome part of the browser is unacceptable. Taras says he thinks > 20 MB (of which 10 MB is for JVM) would be a good target. He also says > that XUL seems to be responsible for about half the memory we do use.
I absolutely think that we need to better understand the memory usage of the content process as well as the chrome process. > > > Taras also said that Alon Zakai told him IPC overhead between main and > content processes is hurting us here.
I keep hearing this anecdotally but have never had anyone actually give us numbers that we could optimize against. There's lots of opportunity to measure and refine message passing overhead, but in contrived tests its so fast that you should normally even notice it's there. > > > A6. Panning/Zooming: Bad/OK. > > I get lots of checkerboarding if I pan quickly, moreso than in other > mobile browsers. Zooming is OK for me, but I do see complaints about it > in the app store, and the graphics quality during zooming is lower than > stock, so maybe we are using that to compensate for lower underlying > performance.
There are tradeoffs that could be made here, but this surprises me greatly. I generally feel that Firefox is just so stupendously better at panning/zooming than stock... For example, we allow you to pan and zoom as fast as the chrome will allow you to do it (which is damn-fast): we asynchronously get updates for the new regions or zoomed pixels. We *could* intentionally slow down scrolling so that you can't scroll as fast (so that painting is more visible), but in general that sounds like the wrong tradeoff. We should definitely look at making the checkerboard less visible (using the page background color etc), but I was pretty sure that this was something where we were winning hands-down, and I'd really like to understand the opposite viewpoint better. > C2. Single-Process Architecture. > > We apparently have evidence that IPC is slowing us down. I don't have > any measurements there, so I don't know much about the problem. But > again, we need to think hard about whether the current multiprocess > architecture is going to get us to where we want to be (taking into > account any predicted improvements in Android IPC) and if it won't, it's > time to do something about that.
We'd have to measure really carefully: the basic trade in multi-process is: * resilience from content misbehaving or large pages causing UI lag * much better UI responsiveness when panning/zooming (although apparently the perception is mixed here!) * increased memory usage * IPC overhead (?) I don't think we can possible make this call until we understand the magnitude of the memory/IPC overhead --BDS |
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mark Finkle |
8/23/11 7:56 AM |
On 08/22/2011 09:18 PM, David Mandelin wrote: > A1. Footprint: Acceptable. > > Installed footprint is 14 MB. Opera Mobile is 12 MB, so it seems we are > not too bad. There are a lot of complaints about this in the App Store, > but I don't think this is going to make or break us. We have plans in progress to remove all bundled L10N packs from the APK. This will reduce the size of the APK by around 310KB per language (uncompressed). We ship 13 other languages besides en-US. That should drop us near or below Opera. Removing the extra languages from an APK resulted in a 12.4MB APK. > Taras told me we could shave off a few MB by eliminating dead code and > making some toolchain tweaks. I don't know how much effort would be > involved. I'm sure there are other things we can do to get some small wins as well. > A2. Startup: Not Good. > > Startup time is 5s. Opera is about the same. Stock is 1.5s. There are a > lot of complaints about this in the App Store. For my personal use, I > don't care too much, because I only start the browser once per crash. > But it probably matters at least somewhat. For some people, startup is around 5s, but we have many other users that see 10s or more. We need to find out why this happens. > I had assumed that stock was faster because it used special tricks to > get pre-started, and so there was not much we could do (taking Opera's > similar score as evidence we are about as good as we can be). But Taras > says that we should be able to get down to 2s on his Galaxy S. He listed > these items as wasted time in startup: > > - 0.5s XUL reflows > - 0.5s sqlite IO (150-1000ms, avg 500) > - ~0.5s linker badness (needs linker improvements) > - unknown needlessly parsing XML, CSS, etc. > > I also tested clicking the app icon when the browser is already open > (maybe this is "warm startup"--not sure what the right term is). I found > that stock is the fastest, with almost no delay, Opera Mobile has a > delay, and Firefox is clearly the slowest. So that area needs help too. I am less worried about getting from 5s to 2s. I am more worried about 10s (or greater) startup times. If we get additional speedups and get to 2s, great - but if the majority of users are still taking ~10s, we still lose. > A3. Memory Usage: Unknown, probably bad. > Looking at the direct measurements, both Taras and I think that ~80 MB > for the chrome part of the browser is unacceptable. Taras says he thinks > 20 MB (of which 10 MB is for JVM) would be a good target. He also says > that XUL seems to be responsible for about half the memory we do use.
There are some simple things we could do. We turned on mjit in chrome hoping for a speed boost. Using mjit adds to our memory usage in chrome. We did not see a boost and I think we should disable mjit in chrome. > > A4. Pageload: Acceptable to Good, but maybe not for everyone. > > I tested Firefox against Opera Mobile and stock by loading 8 pages and > timing the interval between 'click enter' and 'pageload animation stops' > with a stopwatch. Firefox beat both of them on 6 of 8 tests (but not the > same 6). stock was faster on engadget and a bit faster on nytimes, and > Opera was faster on walmart and a hair faster on loading a techcrunch > article. > > Taras seems less sanguine about this--I think his device's smaller RAM > may be the difference. We should get more information about how pageload > looks on different devices and device classes. > > Taras also said that Alon Zakai told him IPC overhead between main and > content processes is hurting us here. Pageload could get a little better in general, but we need to break it out into smaller pieces: Networking, Disk Cache, IPC-affects, and UI updating. * We have no disk cache in Fennec currently. Bugs filed and patches are in progress from the Necko devs. * Tp (with IPC) is around 34% slower than Tp (no IPC) on Android and 52% slower on Maemo. * To avoid making Tp slower, we shied away from updating any UI except the throbber, and we even made the throbber animation 4FPS. We might be able to add some progress updates now that we are multi-process, but the networking still happens in the parent process too. > A6. Panning/Zooming: Bad/OK. > > I get lots of checkerboarding if I pan quickly, moreso than in other > mobile browsers. Zooming is OK for me, but I do see complaints about it > in the app store, and the graphics quality during zooming is lower than > stock, so maybe we are using that to compensate for lower underlying > performance. Panning speed and checkerboarding are two different issues. Checkerboarding relates to the amount of shared image buffering we do across processes. The bigger the buffer, the less checkerboarding - but we use more, sometimes significantly more, memory. If we can improve pure rendering speed, we could use that to offset the need for a bigger buffer. Hardware acceleration is currently the Holy Grail to these problems. Soon we should be able to turn it on and see what happens. > A7. UI Responsiveness: Unknown, probably bad. > > The UI often seems sluggish, and I hear this a lot from other people. > But I tried a simple eyeball test of various UI clicks (e.g., clicking > the location bar) against Opera Mobile and stock, and it seems to me > that the time from 'click' to 'thing I wanted is visible and ready to > use' is usually about the same, with two exceptions: > > - the first time I use a feature (e.g., add-ons manager), it is extra slow > - sometimes there is just a long delay We lazy load as much of the UI as possible to improve startup time. We end up paying the cost later. > So there are a couple of concrete problems, but otherwise it seems OK. > But users still seem to perceive Firefox to be unresponsive, and that > may be the bigger problem: > > - Firefox is unique among mobile browsers in not having a progress bar. > - I notice that Opera Mobile and stock animate other things: e.g., if I > click the options button (the O button on Opera), the option panel > smoothly slides up from the bottom, and the sliding starts instantly on > the click. But in Firefox, nothing happens for a brief interval, then > the panel appears. As noted previously, updating the UI during a pageload can negatively affect pageload speed. Animations have unacceptable performance levels. Hardware acceleration will save us? We'll see.
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Jeff Muizelaar |
8/23/11 8:26 AM |
On 2011-08-23, at 10:56 AM, Mark Finkle wrote:
> Hardware acceleration is currently the Holy Grail to these problems. Soon we should be able to turn it on and see what happens. I'd be careful setting up HW acceleration as the Holy Grail. I expect it to help, but in tests it hasn't been a night and day difference. You can try it out yourself by enabling layers acceleration. -Jeff |
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Joel Stover |
8/23/11 9:03 AM |
CHECKERBOARD If we do hw-accel right, it *should* be the holy grail. The end goal should be: main process uses very little CPU to scroll, giving all of our CPU time to content process. Right now, CPU contention is a big issue, even on multiprocess phones (often times the content process is scheduled on the same processor as the main process to reduce battery drainage). At any rate, most of the checkerboarding issues are perception problems now, IMHO. There are other weird checkerboard cases that have nothing to do with the content process being starved for CPU, especially during loading. You can follow along here for loading: https://bugzilla.mozilla.org/show_bug.cgi?id=680126 There are specific sites that are still simply slow rendering problems, like anything with radial gradients on the background. If you have specific sites, please file bugs! Other checkerboard oddities include: loading images, checkerboard remaining permanently, weird resizing stuff especially when loading pages. PANNING/ZOOMING Readability is a big problem. There's a bug to do some text sizing magic so that when zooming in to a paragraph, it is readable (without messing up layout by being pretty conservative about the algorithm). I don't remember what it is. Otherwise, we're pretty decent on phones. On tablets, we have a problem. The sheer amount of pixels we are pushing takes up our memory bandwidth so scrolling can jerk. Chris Lord is working hard on this problem by trying to do hw-accel right. There are several problems to fix still, but we have an idea of what needs to be done. STARTUP I'm working on a tool that takes function timer logs and parses them into a little piechart (though I am going to turn it into a timeline, as if browser startup is a page load). We have a mobile startup shrink effort here: https://wiki.mozilla.org/Firefox/Projects/Mobile_Startup_Shrink There hasn't been a meeting for a while. I was hoping to have a tool to show before we did another one. Some of my early attempts to classify our pain points are here: http://etherpad.mozilla.com:9000/startupshrink Startup becomes less of an issue if we cut down our memory consumption and stop getting killed by Android. If we could remove methodjit compiled code on memory-pressure, as well as any other caches around (Sqlite!), that could help greatly. There's a good description of the Android killer here: https://bugzilla.mozilla.org/show_bug.cgi?id=675259 In general, my gut tells me memory reduction is the biggest thing we could do to improve our snappiness and general UX. It helps us run on lower end phones too. PAGE LOAD I find this to be pretty acceptable actually, except for the checkerboard perception issues. Ben > _______________________________________________ > dev-planning mailing list > dev-pl...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-planning >
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Matt Brubeck |
8/23/11 10:21 AM |
I have one more category that wasn't included in David's list of topics: Media. HTML5 video is basically unusable in Firefox for Android right now even though the hardware we target is perfectly capable of playing high-quality full-screen video, and in fact we had usable Theora video on Nokia N900 quite a while ago. We need to get video working well on Android with minimal CPU/battery use if we want it to be a credible replacement for Flash. OpenGL and other graphics optimizations are part of the answer. Also, Android 3.x ships with its own WebM decoder libraries which I believe take advantage of hardware decoders where available; have we looked into using those?
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Boris Zbarsky |
8/23/11 11:31 AM |
On 8/23/11 2:24 PM, Ehsan Akhgari wrote: > On 11-08-22 10:50 PM, Boris Zbarsky wrote: >> Have we considered prototyping out a front-end that uses XUL _markup_ >> but uses an HTMLDocument for the actual document? That would avoid the >> proto document thing going on (though it would lose fastload and the >> like, of course; I'm primarily interested in the memory usage for the >> moment). >
> Is that just about putting the entire XUL DOM inside an HTML document? Yep. XHTML document, presumably. > That should be a very short patch to try... Maybe. XUL parsing differs from normal XML parsing (e.g. in its whitespace handling) so there could be all sorts of glitches when actually doing this if scripts assume things about indexing. -Boris |
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Boris Zbarsky |
8/23/11 11:32 AM |
On 8/23/11 2:31 PM, Boris Zbarsky wrote: >> That should be a very short patch to try... > > Maybe. XUL parsing differs from normal XML parsing (e.g. in its > whitespace handling) so there could be all sorts of glitches when > actually doing this if scripts assume things about indexing. Also, the whole overlay system is tied to XULDocument, so wouldn't work when an XHTML document is used. -Boris
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
azakai |
8/23/11 11:43 AM |
On Aug 23, 7:54 am, Benjamin Smedberg < benja...@smedbergs.us> wrote: > On 8/22/2011 9:18 PM, David Mandelin wrote: > > > Taras also said that Alon Zakai told him IPC overhead between main and > > content processes is hurting us here. > > I keep hearing this anecdotally but have never had anyone actually give > us numbers that we could optimize against. There's lots of opportunity > to measure and refine message passing overhead, but in contrived tests > its so fast that you should normally even notice it's there. > I don't recall the exact numbers from last year, but there were two main issues: 1. Sync messages. We worked hard and removed almost all of those. However a few remain, for example the Paint sync message, which will be very hard to make async without using more memory. 2. General overhead of a two-process model. More memory is used, we have more threads/timers/etc. (for example, GC timer stuff is doubled), etc. Even after removing almost all sync messages, we saw a significant slowdown with single-process vs multi-process Fennec in things like page load times. > > We'd have to measure really carefully: the basic trade in multi-process is: > > * resilience from content misbehaving or large pages causing UI lag > * much better UI responsiveness when panning/zooming (although > apparently the perception is mixed here!) > * increased memory usage > * IPC overhead (?) > > I don't think we can possible make this call until we understand the > magnitude of the memory/IPC overhead > The better UI responsiveness with multi-process is huge IMO. Single-process Fennec is very sluggish in comparison. Single-process saves memory and some other overhead, which in theory makes sense for low-end phones, but it is exactly those low-end phones where the bad UI responsiveness in single-process Fennec is at its worst. - azakai
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Ehsan Akhgari |
8/23/11 11:48 AM |
On 11-08-23 10:54 AM, Benjamin Smedberg wrote: > We'd have to measure really carefully: the basic trade in multi-process is: > > * resilience from content misbehaving or large pages causing UI lag > * much better UI responsiveness when panning/zooming (although > apparently the perception is mixed here!) > * increased memory usage > * IPC overhead (?) Also, * Resilience against OOM crashes with ridiculously large web pages. I get this from time to time on Fennec. (I don't have a lot of RAM on my phone.) Ehsan
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Axel Hecht |
8/23/11 2:18 PM |
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Kadir Topal |
8/23/11 5:31 PM |
Mark Finkle schrieb: > On 08/22/2011 09:18 PM, David Mandelin wrote: >> I had assumed that stock was faster because it used special tricks to >> get pre-started, and so there was not much we could do (taking Opera's >> similar score as evidence we are about as good as we can be). But Taras >> says that we should be able to get down to 2s on his Galaxy S. He listed >> these items as wasted time in startup: >> >> - 0.5s XUL reflows >> - 0.5s sqlite IO (150-1000ms, avg 500) >> - ~0.5s linker badness (needs linker improvements) >> - unknown needlessly parsing XML, CSS, etc. >> >> I also tested clicking the app icon when the browser is already open >> (maybe this is "warm startup"--not sure what the right term is). I found >> that stock is the fastest, with almost no delay, Opera Mobile has a >> delay, and Firefox is clearly the slowest. So that area needs help too. > > I am less worried about getting from 5s to 2s. I am more worried about > 10s (or greater) startup times. If we get additional speedups and get to > 2s, great - but if the majority of users are still taking ~10s, we still > lose. This one I don't agree with. If Firefox takes 5 seconds to load and the stock browser takes 1.5 seconds, I'm not going to use Firefox. On my mobile I usually need Firefox to quickly check something, so 2 or 5 seconds can be the difference between make and break. -Kadir
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Taras Glek |
8/23/11 5:41 PM |
On 08/22/2011 09:07 PM, L. David Baron wrote: > On Tuesday 2011-08-23 15:32 +1200, Robert O'Callahan wrote: >> Great write-up! >> >> On Tue, Aug 23, 2011 at 1:18 PM, David Mandelin< dman...@mozilla.com>wrote: >> >>> - 0.5s XUL reflows >>> >> >> We should be able to fix this in layout. The old XUL flexbox code is pretty >> crazy but Daniel Holbert has a new implementation of CSS3 flexbox that >> should be better. It would be helpful if someone imported the Fennec UI into >> a standalone test page for easy performance analysis. > > I suspect this isn't actually reflow, though. In XUL documents a > lot of stuff, including frame construction and style resolution, > happens inside of PresShell::InitialReflow. The previous times I've > seen reflow accused of being this portion of a profile, it was > actually "all the stuff inside PresShell::InitialReflow" being > accused. Here is what I'm using to measure. You are right about 200-300ms of that is initial reflow + a further 50-300ms (not sure why it varies so much) for further reflows. I still think the total cost here should be closer to 0 than it is right now. I filed regarding adding these measurements to telemetry https://bugzilla.mozilla.org/show_bug.cgi?id=681535 > > *Lots* of stuff in layout happens lazily, so if you want to break > down time spent in style vs. frame construction vs. reflow, you > really need to split profiles using a tool like > http://mxr.mozilla.org/mozilla-central/source/tools/jprof/split-profile.pl > For more details, see my posts on 2010-05-06 to dev.platform in the > thread "Startup Timeline - Can you help?" which unfortunately are > not archived on google groups as far as I can tell. I didn't see anything particularly enlightening in that thread. Taras
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Robert O'Callahan |
8/23/11 6:20 PM |
On Wed, Aug 24, 2011 at 2:56 AM, Mark Finkle <mark....@gmail.com> wrote: > On 08/22/2011 09:18 PM, David Mandelin wrote: >
> A2. Startup: Not Good. >> >> Startup time is 5s. Opera is about the same. Stock is 1.5s. There are a >> lot of complaints about this in the App Store. For my personal use, I >> don't care too much, because I only start the browser once per crash. >> But it probably matters at least somewhat. >> > > For some people, startup is around 5s, but we have many other users that > see 10s or more. We need to find out why this happens. On my Nexus S, startup is about 2s to showing the browser window, then maybe another 1s before the home screen is fully visible. I'm shocked it's 5s for some people! :-)
Rob -- "If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us." [1 John 1:8-10]
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mark Finkle |
8/23/11 6:23 PM |
On 08/23/2011 10:30 AM, Robert Kaiser wrote: > Jonas Sicking schrieb: >> Note that non-XUL doesn't need to mean non-Gecko. One option is to >> build a front-end in HTML. I think the HTML code has received a lot >> more performance love than the XUL code in many areas. > > I think that HTML still needs some love to measure up to XUL in terms of > using it for UI, but starting with converting Fennec UI over might be > the right thing because it has relatively little UI compared to > everything else and improving HTML for the things needed there is > probably a good start. I can't see using HTML to replace XUL until we have XBL2 (or simialr) to create reusable bindings for widgets. I, for one, am not interested in building applications using <ul> and <li> and clumsy wrappers for JS and event encapsulation. When we can create reusable widgets based on HTML, we should start using it.
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
David Mandelin |
8/23/11 6:36 PM |
This ties in to another idea I had for mobile. I get the impression that fully general HTML layout is slow on mobile. After all, the typical device-power/content-complexity ratio was much different when HTML and CSS were designed. So: Can we create extensions for HTML that support cheap (in time and energy) layout of mobile apps? Maybe an XBL2-type thing, but with the intent of having it work for mobile content as well, and eventually getting it into the (HTML or other appropriate) standards? Dave
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
David Mandelin |
8/23/11 6:40 PM |
On 8/22/2011 7:50 PM, Boris Zbarsky wrote: > On 8/22/11 9:18 PM, David Mandelin wrote: >> Looking at the direct measurements, both Taras and I think that ~80 MB >> for the chrome part of the browser is unacceptable. Taras says he thinks >> 20 MB (of which 10 MB is for JVM) would be a good target. He also says >> that XUL seems to be responsible for about half the memory we do use. > > How many XUL elements do we end up with in the Fennec chrome once all > XBL bindings are instantiated? > >> B1. Fully understand memory usage. This means: know what all the >> different memory metrics mean, make sure they all fit together, and >> understand how different features of Firefox's architecture and design >> affect memory usage. > > There's been a bunch of progress on about:memory since the Fx6 build you > tested, including a lot more stuff being classified now. Worth testing > with a nightly. Gah, Nick Nethercote even warned me about this, but in the original message I forgot to say that I redid the memory stats in Nightly and reported the new ones. In 6, 50-60% was dark matter, so there has indeed been a big improvement. >> For example, you can use the Netflix queue management page from a tablet >> or smartphone, but it's painfully slow--*barely* usable. What can we do >> to make it fully usable? > > Profile it, for a start? I'd dearly love to see some profile data here, > or any howto on android profiling we have around if we have one... I don't think we're there yet, but it looks like there is something that just about works in https://bugzilla.mozilla.org/show_bug.cgi?id=674986 Dave
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
David Mandelin |
8/23/11 6:41 PM |
On 8/22/2011 8:16 PM, Justin Lebar wrote: >>> B1. Fully understand memory usage. This means: know what all the >>> different memory metrics mean, make sure they all fit together, and >>> understand how different features of Firefox's architecture and design >>> affect memory usage. >> >> There's been a bunch of progress on about:memory since the Fx6 build you >> tested, including a lot more stuff being classified now. Worth testing >> with a nightly. >>
>> If the 2x gap between 'resident' and 'heap-comitted' is still there in >> current nightlies, we should try to understand it. > > heap-committed is basically meaningless except with jemalloc on Windows. This is reflected in its description in the latest about:memory. > > Bug 674290 should work on Android and should help us understand any gap between resident and heap usage. I'm definitely looking forward to that bug. Dave
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
David Mandelin |
8/23/11 6:45 PM |
On 8/22/2011 8:11 PM, Matt Brubeck wrote: > Thanks a lot for this list, by the way. Here are some pointers to > existing work for anyone who is curious or who wants to know of places > to get started. Thanks for your very detailed pointers to the existing work. I haven't had a chance to check them out yet, though, so just responding to a few general points now. > On 08/22/2011 06:18 PM, David Mandelin wrote: >> D5. Add a progress bar for pageload. > > We'll soon replace the current 4fps throbber with a much smoother one > that is two-state (like desktop Firefox) to provide better perceived > smoothness and better feedback on the loading process: > > https://bugzilla.mozilla.org/show_bug.cgi?id=679927 But why not a full progress bar? Pageload times were 2-20s in my tests--if I'm going to wait 10s I'd like to see a growing bar, not just a throbber. >> D6. Add animations for UI actions. > > This has long been blocked on making animations smooth enough to be > usable on mobile. With some in-review patches to reduce reflows during > animation, this is apparently doable now and should land soon. Patches > along with lots of history and discussion here: > > https://bugzilla.mozilla.org/show_bug.cgi?id=524925 That's a good development. This also seems like an argument in favor of a new (or modified; e.g. the "standardizable XBL2") front-end architecture. Dave
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
David Mandelin |
8/23/11 6:47 PM |
On 8/22/2011 10:35 PM, Mike Hommey wrote: > On Mon, Aug 22, 2011 at 06:18:33PM -0700, David Mandelin wrote: >> - 0.5s XUL reflows
>> - 0.5s sqlite IO (150-1000ms, avg 500) >> - ~0.5s linker badness (needs linker improvements)
> That's actually more like 0.8 to 1s when you don't have enough space on > your device, and ~0.3s when you do. Though the first start is then > abysmal, as writing the decompressed files usually takes more than 2s. > We should delay that decompression. Speaking of the first start, > creating the profile is also taking a whole lot of time, and really > doesn't help making a first good impression. I must confess I don't actually know what the linker badness really is. Do we have a bug on file for that, or could you provide a quick description for those of us not in the know. >> - unknown needlessly parsing XML, CSS, etc.
> - 0.2 to 0.3s between the process starting and our code actually > starting. :( > > We should aim at having the UI show up under 1.5s, which is optimistic, > but I think is possible. Excellent! > One of the problems is that we do lot of things > during startup that could just wait after the UI, or a part of it, is > displayed to the user. I think Sqlite I/O happens before the UI is > displayed, for example. We could delay NSS loading, too, as well as a > whole lot of things we don't use during startup. These would not only > help mobile startup, but desktop, too. Totally makes sense. Dave
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
David Mandelin |
8/23/11 6:49 PM |
On 8/23/2011 7:26 AM, Robert Kaiser wrote: > David Mandelin schrieb: >> - Firefox is unique among mobile browsers in not having a progress bar. > > Firefox on both mobile and desktop does not give a whole lot of feedback > of "loading a page", which I have seen to cause confusion for users a > number of times when I watched them doing things on the web. > >> Taras found that XUL about doubles our memory usage. That's pretty bad. >> It also likely slows things down. I think we should seriously consider >> creating a new, non-XUL front end for Android. > > 1) We don't have any good support for embedding Gecko in native apps > right now, we'd need to build that from scratch - and we would make it > impossible to use this frontend on any other mobile system or run Fennec > on desktop for testing the way we do now if we go with a Android-native > interface. It also would kill a lot of possibilities of add-ons. The add-on question is difficult. I don't know a lot about it, but I was vaguely hoping that we could provide a good subset of the add-on API (APIs?) on top of a new architecture. The HTML-like or better-XUL-front-end ideas seem to avoid that problem, though. We'd probably still want an escape hatch to patch in some native Android stuff where it really counts. Dave
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
David Mandelin |
8/23/11 6:58 PM |
On 8/23/2011 7:54 AM, Benjamin Smedberg wrote: > On 8/22/2011 9:18 PM, David Mandelin wrote: >> A6. Panning/Zooming: Bad/OK. >> >> I get lots of checkerboarding if I pan quickly, moreso than in other >> mobile browsers. Zooming is OK for me, but I do see complaints about it >> in the app store, and the graphics quality during zooming is lower than >> stock, so maybe we are using that to compensate for lower underlying >> performance. > There are tradeoffs that could be made here, but this surprises me > greatly. I generally feel that Firefox is just so stupendously better at > panning/zooming than stock... > > For example, we allow you to pan and zoom as fast as the chrome will > allow you to do it (which is damn-fast): we asynchronously get updates > for the new regions or zoomed pixels. Good point! I just retested scrolling techcrunch, and I found that: - Opera Mobile was slow and smooth - Stock was fast and jerky - Firefox was very fast and checkerboardy Fast, smooth, no checkerboards: pick 2. > We *could* intentionally slow down > scrolling so that you can't scroll as fast (so that painting is more > visible), but in general that sounds like the wrong tradeoff. I think I agree, but I'm not sure yet. Opera has a feature where if you scroll fast, they show a button with an up or down arrow that will scroll you all the way, which I thought was just generally neat, but they might also have added it to mitigate their slower scrolling. > We should definitely look at making the checkerboard less visible (using > the page background color etc), but I was pretty sure that this was > something where we were winning hands-down, and I'd really like to > understand the opposite viewpoint better. At this point, I'd have to spend more time in the different browsers to which I liked more. I'm pretty sure I especially dislike jerkiness, though. Opera's choice has the virtue of a very consistent response to user input, which I think is a great feature for controls. But it does cost something in how much response you can get for your input. >> C2. Single-Process Architecture. >> >> We apparently have evidence that IPC is slowing us down. I don't have >> any measurements there, so I don't know much about the problem. But >> again, we need to think hard about whether the current multiprocess >> architecture is going to get us to where we want to be (taking into >> account any predicted improvements in Android IPC) and if it won't, it's >> time to do something about that. > We'd have to measure really carefully: the basic trade in multi-process is: > > * resilience from content misbehaving or large pages causing UI lag > * much better UI responsiveness when panning/zooming (although > apparently the perception is mixed here!) > * increased memory usage > * IPC overhead (?) >
> I don't think we can possible make this call until we understand the > magnitude of the memory/IPC overhead Agreed. A third option is to get a lot more creative about how we use multiple processes. Dave
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Boris Zbarsky |
8/23/11 7:04 PM |
On 8/23/11 9:23 PM, Mark Finkle wrote: > I can't see using HTML to replace XUL until we have XBL2 (or simialr) to > create reusable bindings for widgets. You can use XBL1 with HTML, fwiw. -Boris
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
David Mandelin |
8/23/11 7:05 PM |
On 8/23/2011 7:56 AM, Mark Finkle wrote: > On 08/22/2011 09:18 PM, David Mandelin wrote: > >> A1. Footprint: Acceptable. >> >> Installed footprint is 14 MB. Opera Mobile is 12 MB, so it seems we are >> not too bad. There are a lot of complaints about this in the App Store, >> but I don't think this is going to make or break us. > > We have plans in progress to remove all bundled L10N packs from the APK. > This will reduce the size of the APK by around 310KB per language > (uncompressed). We ship 13 other languages besides en-US. That should > drop us near or below Opera. Removing the extra languages from an APK > resulted in a 12.4MB APK. That sounds nice. I assume we're going to keep it super-easy to add a language pack. >> A3. Memory Usage: Unknown, probably bad. > >> Looking at the direct measurements, both Taras and I think that ~80 MB >> for the chrome part of the browser is unacceptable. Taras says he thinks >> 20 MB (of which 10 MB is for JVM) would be a good target. He also says >> that XUL seems to be responsible for about half the memory we do use. >
> There are some simple things we could do. We turned on mjit in chrome > hoping for a speed boost. Using mjit adds to our memory usage in chrome. > We did not see a boost and I think we should disable mjit in chrome. Yes. Let's do that right away. I should note here that Luke Wagner has recently found that in general JS uses a ton of memory for scripts (class JSScript). I can't recall where that info is, but there is an idea about how to fix it here: https://bugzilla.mozilla.org/show_bug.cgi?id=679940 >> A4. Pageload: Acceptable to Good, but maybe not for everyone. >> >> I tested Firefox against Opera Mobile and stock by loading 8 pages and >> timing the interval between 'click enter' and 'pageload animation stops' >> with a stopwatch. Firefox beat both of them on 6 of 8 tests (but not the >> same 6). stock was faster on engadget and a bit faster on nytimes, and >> Opera was faster on walmart and a hair faster on loading a techcrunch >> article. >> >> Taras seems less sanguine about this--I think his device's smaller RAM >> may be the difference. We should get more information about how pageload >> looks on different devices and device classes. >> >> Taras also said that Alon Zakai told him IPC overhead between main and >> content processes is hurting us here. >
> Pageload could get a little better in general, but we need to break it > out into smaller pieces: Networking, Disk Cache, IPC-affects, and UI > updating. > > * We have no disk cache in Fennec currently. Bugs filed and patches are > in progress from the Necko devs. > * Tp (with IPC) is around 34% slower than Tp (no IPC) on Android and 52% > slower on Maemo. This just seems like a huge opportunity. I don't know if it would hold up on all devices, but on my device, if we could make pageload 34% faster, Firefox would be the clear winner. > * To avoid making Tp slower, we shied away from updating any UI except > the throbber, and we even made the throbber animation 4FPS. We might be > able to add some progress updates now that we are multi-process, but the > networking still happens in the parent process too. > >> A6. Panning/Zooming: Bad/OK. >> >> I get lots of checkerboarding if I pan quickly, moreso than in other >> mobile browsers. Zooming is OK for me, but I do see complaints about it >> in the app store, and the graphics quality during zooming is lower than >> stock, so maybe we are using that to compensate for lower underlying >> performance. >
> Panning speed and checkerboarding are two different issues. > Checkerboarding relates to the amount of shared image buffering we do > across processes. The bigger the buffer, the less checkerboarding - but > we use more, sometimes significantly more, memory. If we can improve > pure rendering speed, we could use that to offset the need for a bigger > buffer. It seems like the problems and tradeoffs are tough here. (See also bsmedberg's comment and my reply.) This one might be about perceived performance more than anything. > Hardware acceleration is currently the Holy Grail to these problems. > Soon we should be able to turn it on and see what happens. > >> A7. UI Responsiveness: Unknown, probably bad. >> >> The UI often seems sluggish, and I hear this a lot from other people. >> But I tried a simple eyeball test of various UI clicks (e.g., clicking >> the location bar) against Opera Mobile and stock, and it seems to me >> that the time from 'click' to 'thing I wanted is visible and ready to >> use' is usually about the same, with two exceptions: >> >> - the first time I use a feature (e.g., add-ons manager), it is >> extra slow >> - sometimes there is just a long delay > > We lazy load as much of the UI as possible to improve startup time. We > end up paying the cost later. I think that particular item is the least important one in UI responsiveness. If we can fix it, great. But I don't think it's a huge deal and it's definitely not worth taking a startup hit. >> So there are a couple of concrete problems, but otherwise it seems OK. >> But users still seem to perceive Firefox to be unresponsive, and that >> may be the bigger problem: >> >> - Firefox is unique among mobile browsers in not having a progress bar.
>> - I notice that Opera Mobile and stock animate other things: e.g., if I >> click the options button (the O button on Opera), the option panel >> smoothly slides up from the bottom, and the sliding starts instantly on >> the click. But in Firefox, nothing happens for a brief interval, then >> the panel appears. > > As noted previously, updating the UI during a pageload can negatively > affect pageload speed. > Animations have unacceptable performance levels. Hardware acceleration > will save us? We'll see. What aspect of animation exactly has an unacceptable impact? All the other browsers do progress bar and control-showing animations, so there must be some way to do it. (Or are they paying something nontrivial for that progress bar? I'd love to know.) Dave
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
L. David Baron |
8/23/11 8:02 PM |
On Tuesday 2011-08-23 18:36 -0700, David Mandelin wrote: > This ties in to another idea I had for mobile. I get the impression that > fully general HTML layout is slow on mobile. After all, the typical > device-power/content-complexity ratio was much different when HTML and > CSS were designed. So: > > Can we create extensions for HTML that support cheap (in time and > energy) layout of mobile apps? Maybe an XBL2-type thing, but with the > intent of having it work for mobile content as well, and eventually > getting it into the (HTML or other appropriate) standards? The desktop computers we used when HTML and CSS were designed were considerably less powerful than today's mobile phones. It's just that content complexity has gone up in proportion to what's tolerable on desktops, and mobiles are behind desktops. I think many of today's sites use an excessive amount of HTML and CSS for what they're trying to accomplish, though (often because they're using a bunch of frameworks in the middle each of which adds a bunch of complexity). I think that's best fixed by providing layout primitives that better match what authors want to accomplish, so they can use those primitives more directly rather than putting a bunch of layers of abstraction in between. I don't think they need to be more efficient than today's primitives, though they probably do need to be similar in efficiency. -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla Corporation http://www.mozilla.com/ 𝄂
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mark Finkle |
8/23/11 8:10 PM |
On 08/23/2011 09:45 PM, David Mandelin wrote: > On 8/22/2011 8:11 PM, Matt Brubeck wrote: >> We'll soon replace the current 4fps throbber with a much smoother one >> that is two-state (like desktop Firefox) to provide better perceived >> smoothness and better feedback on the loading process: >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=679927 > > But why not a full progress bar? Pageload times were 2-20s in my > tests--if I'm going to wait 10s I'd like to see a growing bar, not just > a throbber. We need to be careful. Progress notifications are sent to the chrome process via IPC messages from the content process. We ahve already found that removing onProgress and onStatus message overhead during pageload improved Tp by almost 10%. See bug 622536 and bug 632005 and bug 588441 and bug 633442. onProgress in particular is very chatty. We could throttle it and try to get a simple progress bar, maybe incrementing every 10%. Heck, even the 4fps throbber was used because the CPU spiked to almost 100%, just to display the higher FPS animated image.
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Joe Drew |
8/23/11 8:17 PM |
On 2011-08-23 9:45 PM, David Mandelin wrote: >> We'll soon replace the current 4fps throbber with a much smoother one >> that is two-state (like desktop Firefox) to provide better perceived >> smoothness and better feedback on the loading process: >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=679927 > > But why not a full progress bar? Pageload times were 2-20s in my > tests--if I'm going to wait 10s I'd like to see a growing bar, not just > a throbber.
Progress bars don't really make sense on the web, unfortunately. While you can tell how long your first resource load (i.e., the page) will take (usually), there's absolutely no way to know ahead of time how big each of the subsequent resource loads will be. This means that the progress bar will either jump around or stall for long periods of time. For example, imagine a page that has, as its last part of markup, <img src="somebigimage.png" /> - a 4 MB image. The rest of the page is 1 kB. The browser originally thought it was 99% finished loading, but it has suddenly discovered it is actually less than 1% finished loading. What is a good progress bar presentation for this situation? AIUI from discussions with Beltzner, this is one of several reasons the progress bar was removed from desktop Firefox. Joe
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Joe Drew |
8/23/11 8:21 PM |
On 2011-08-23 1:35 AM, Mike Hommey wrote: > We should aim at having the UI show up under 1.5s,
I would go even further: set a goal of having Fennec up and running, and responsive to interaction, in 1s. This is what folks working on making Linux boot fast did[1]. If you say "We should boot faster", you look at making 10% improvements. If you say "We should boot fast", you look at the problem in a totally different way. Joe 1. https://lwn.net/Articles/299483/
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mark Finkle |
8/23/11 8:22 PM |
On 08/23/2011 08:31 PM, Kadir Topal wrote: > > > Mark Finkle schrieb: >> I am less worried about getting from 5s to 2s. I am more worried about >> 10s (or greater) startup times. If we get additional speedups and get to >> 2s, great - but if the majority of users are still taking ~10s, we still >> lose. > > This one I don't agree with. If Firefox takes 5 seconds to load and the > stock browser takes 1.5 seconds, I'm not going to use Firefox. On my > mobile I usually need Firefox to quickly check something, so 2 or 5 > seconds can be the difference between make and break. I agree, but my point is: If we see 5s startup times now, but many other people still see >10s startup times, getting the fastest startup to 2s doesn't matter if many people still see ~10s startups. Just because 20% of our users see fast startup times mean nothing if the majority still see slow startup times. We need to figure out why all of our users are not seeing ~5s startup times right now. In fact, I remember you filed a bug about horrible startup times yourself. No one else could reproduce the slow startup you were experiencing.
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Jason Duell |
8/23/11 8:29 PM |
>> But why not a full progress bar? Pageload times were 2-20s in my >> tests--if I'm going to wait 10s I'd like to see a growing bar, not just >> a throbber. > > We need to be careful. Progress notifications are sent to the chrome > process via IPC messages from the content process. We ahve already > found that removing onProgress and onStatus message overhead during > pageload improved Tp by almost 10%. > > See bug 622536 and bug 632005 and bug 588441 and bug 633442.
We currently piggyback OnStatus/OnProgress messages on top of the OnDataAvailable IPDL messages, so they're happening as often as they do in single-process gecko, but with minimal IPC overhead. So there's no IPC consideration AFAICT in implementing a progress bar--the OnProgress/Status notifications are basically free now. The issue is whether you want to actually update the progress bar at every OnProgress call, (sounds like it incur too much animation overhead). > > onProgress in particular is very chatty. We could throttle it and try > to get a simple progress bar, maybe incrementing every 10%. > That ought to be easy to do. Jason > Heck, even the 4fps throbber was used because the CPU spiked to almost > 100%, just to display the higher FPS animated image.
> _______________________________________________ > dev-planning mailing list > dev-pl...@lists.mozilla.org> https://lists.mozilla.org/listinfo/dev-planning |
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mark Finkle |
8/23/11 8:31 PM |
On 08/23/2011 10:05 PM, David Mandelin wrote: > On 8/23/2011 7:56 AM, Mark Finkle wrote: >> On 08/22/2011 09:18 PM, David Mandelin wrote: >>
>> We have plans in progress to remove all bundled L10N packs from the APK. >> This will reduce the size of the APK by around 310KB per language >> (uncompressed). We ship 13 other languages besides en-US. That should >> drop us near or below Opera. Removing the extra languages from an APK >> resulted in a 12.4MB APK. > > That sounds nice. I assume we're going to keep it super-easy to add a > language pack. Yes, in fact the code has already landed. We need some extra work, server-side, from RelEng to make sure compatible langpacks are available as Nightly users update. We don't want to get into a situation where the Nightly is updated, but the langpack is busted, making the Nightly busted as well. >>> A3. Memory Usage: Unknown, probably bad. >> >>> Looking at the direct measurements, both Taras and I think that ~80 MB >>> for the chrome part of the browser is unacceptable. Taras says he thinks >>> 20 MB (of which 10 MB is for JVM) would be a good target. He also says >>> that XUL seems to be responsible for about half the memory we do use. >> >> There are some simple things we could do. We turned on mjit in chrome >> hoping for a speed boost. Using mjit adds to our memory usage in chrome. >> We did not see a boost and I think we should disable mjit in chrome. > > Yes. Let's do that right away. Filing a bug now. >> Animations have unacceptable performance levels. Hardware acceleration >> will save us? We'll see. > > What aspect of animation exactly has an unacceptable impact? All the > other browsers do progress bar and control-showing animations, so there > must be some way to do it. (Or are they paying something nontrivial for > that progress bar? I'd love to know.) When animating parts of the UI, like making menus slide out or making dialogs fade in, things can get jerky and not look smooth. There are bugs and some patches on some of these issues. Those, coupled with faster rendering should get us to acceptable performance. Even so, if the animation is taxing the CPU, we could be negatively affecting the actual work we are trying make appear faster. We should know soon enough. Patches for both improving rendering and adding animations are due to land on Nightly soon.
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Joel Stover |
8/23/11 8:32 PM |
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Joe Drew |
8/23/11 8:38 PM |
On 2011-08-23 11:32 PM, Benjamin Stover wrote: > I think one of the things we're going to need is something like > about:memory, that allows people to get a timeline of exactly what is > slow in their startup path for those worst cases.
Yes. Bootchart, as mentioned in the LWN link in my original post, was essential in making up a startup time budget. We should use it, or something like it, and make sure it's built in to everybody's Firefox. And then we should allocate all our subsystems N ms to start up (on a given piece of hardware), and make that happen. > Maybe we could adjust > function timers to be much faster and enable them by default. IIRC, function timers were totally removed - please correct me if I'm wrong.
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Joel Stover |
8/23/11 8:52 PM |
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Justin Lebar |
8/23/11 9:57 PM |
I think we should consider aggressively dropping mjit/tjit code/data. Background tabs, for instance, shouldn't keep this around. And maybe we could avoid keeping around jit'ed code for things like the Google +1 and Facebook like iframes. I imagine that most pages run a lot of JS on load and then run very little. We could notice this and drop into the interpreter after load. The network on these devices is so slow, we may be able to trade off some JS perf for memory without making a noticeable difference.
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Nicholas Nethercote |
8/23/11 10:11 PM |
On Tue, Aug 23, 2011 at 9:57 PM, Justin Lebar <justin...@gmail.com> wrote: > I think we should consider aggressively dropping mjit/tjit code/data. I believe bhackett's type inference work (which should land on m-c soon) has turned up the aggression on mjit code/data dropping. And turning off mjit for chrome is a no-brainer: it increased memory usage for no noticeable effect :( Nick
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
L. David Baron |
8/23/11 8:27 PM |
On Tuesday 2011-08-23 17:41 -0700, Taras Glek wrote: > On 08/22/2011 09:07 PM, L. David Baron wrote: > >On Tuesday 2011-08-23 15:32 +1200, Robert O'Callahan wrote: > >>Great write-up! > >> > >>On Tue, Aug 23, 2011 at 1:18 PM, David Mandelin<dman...@mozilla.com>wrote: > >> > >>>- 0.5s XUL reflows > >>> > >> > >>We should be able to fix this in layout. The old XUL flexbox code is pretty > >>crazy but Daniel Holbert has a new implementation of CSS3 flexbox that > >>should be better. It would be helpful if someone imported the Fennec UI into > >>a standalone test page for easy performance analysis. > > > >I suspect this isn't actually reflow, though. In XUL documents a > >lot of stuff, including frame construction and style resolution, > >happens inside of PresShell::InitialReflow. The previous times I've > >seen reflow accused of being this portion of a profile, it was > >actually "all the stuff inside PresShell::InitialReflow" being > >accused. > > Here is what I'm using to measure. You are right about 200-300ms of > that is initial reflow + a further 50-300ms (not sure why it varies > so much) for further reflows. I still think the total cost here > should be closer to 0 than it is right now. > > I filed regarding adding these measurements to telemetry > https://bugzilla.mozilla.org/show_bug.cgi?id=681535 So the measurements in that bug are going to measure a lot more than just Reflow, last I checked, particularly for XUL (where, if my memory is correct, we don't do incremental layout and all frame construction and style resolution happens within PresShell::InitialReflow). And, actually, now that I look at the code, no reflow actually even happens inside of PresShell::InitialReflow, since it just posts a reflow event (see bug 378975). Even if that patch is fixed to only measure ProcessReflowCommands (which is a reasonable point for measuring time spent within reflow), it's still subject to dealing with laziness within layout (see below). This sort of function-timing telemetry has to be accompanied by some profiling of what happens inside the time that you're measuring. Otherwise you don't know what it is that needs to be fixed. > >*Lots* of stuff in layout happens lazily, so if you want to break > >down time spent in style vs. frame construction vs. reflow, you > >really need to split profiles using a tool like > >http://mxr.mozilla.org/mozilla-central/source/tools/jprof/split-profile.pl > >For more details, see my posts on 2010-05-06 to dev.platform in the > >thread "Startup Timeline - Can you help?" which unfortunately are > >not archived on google groups as far as I can tell. > > I didn't see anything particularly enlightening in that thread. Basically, there are a large number of things in layout that happen lazily. Some information becomes invalid, and instead of recomputing it immediately, we just mark it invalid. This is important because there might be 100 different things that mark it invalid before we next actually need the information. Then, when we need the information, we (re)compute it. This makes attributing blame to a particular subsystem within layout (e.g., CSS cascading, CSS selector matching, font matching, style computation, frame construction, reflow/layout) more complicated than just timing the duration of a particular function. The only accurate way I know to do this is to take a profile and slice it into sets, starting by slicing out the leaf-most actions (i.e., the ones that don't nest any other things), and then the ones that only nest inside of them the things already sliced out, etc. This is what split-profile.pl does. Getting these splits correct requires looking at the profile data within each split to make sure it represents a single task. An example (very out-of-date, but quite accurate at the time) set of splitting rules is provided within this attachment: https://bugzilla.mozilla.org/show_bug.cgi?id=144533#c40 -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla Corporation http://www.mozilla.com/ 𝄂
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Wesley Johnston |
8/23/11 10:20 PM |
> I think I agree, but I'm not sure yet. Opera has a feature where if you > scroll fast, they show a button with an up or down arrow that will > scroll you all the way, which I thought was just generally neat, but > they might also have added it to mitigate their slower scrolling. We actually have a feature in Fennec where two finger up or down swipes will take you to the top and bottom of documents (left and right move back and forward in history), and will usually show checkerboard for a half second or so while we draw. The other day my wife was complaining about checkerboarding and I realized that she was unintentionally two finger swiping and didn't understand what was going on. So some of these probably fall in the category of things we could do more slowly, but with better perceived performance (bugs 641816 and 653092). We have a few other simple fixes that should help panning lying around, but like has been said, we don't have any metrics that really let us know if they are actually helping or not. Just people saying, "I like this one!". I'm working with stechz to get the tools we need, and some simple tests written. I'm going to try and get that up in bug 607777 soon. - wesj
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mike Hommey |
8/23/11 11:46 PM |
On Tue, Aug 23, 2011 at 06:47:13PM -0700, David Mandelin wrote: > On 8/22/2011 10:35 PM, Mike Hommey wrote: > > On Mon, Aug 22, 2011 at 06:18:33PM -0700, David Mandelin wrote: > >> - 0.5s XUL reflows > >> - 0.5s sqlite IO (150-1000ms, avg 500) > >> - ~0.5s linker badness (needs linker improvements) > > That's actually more like 0.8 to 1s when you don't have enough space on > > your device, and ~0.3s when you do. Though the first start is then > > abysmal, as writing the decompressed files usually takes more than 2s. > > We should delay that decompression. Speaking of the first start, > > creating the profile is also taking a whole lot of time, and really > > doesn't help making a first good impression. > > I must confess I don't actually know what the linker badness really is. > Do we have a bug on file for that, or could you provide a quick > description for those of us not in the know. As our binary footprint is much more than the 12~13MB of the apk, having the apk uncompressed on the system filesystem can be eating a lot of its resources on small devices. So, when we detect there is not enough space in the system filesystem for our files, we uncompress our binaries at startup, in memory (ashmem, to be precise). Uncompressing takes around 600~700ms on a Nexus S. The easiest way to get that down is to uncompress less things, which is not that easy when you basically have one file that represents 87% of what you uncompress. So we should IMHO try to shrink libxul by making components of things we don't need immediately. This would require changes to our dynamic linker to support compressed components. When we do have enough space, we extract and store our binaries on the system filesystem, and load the files from there. The downside is that while extraction itself is 600~700ms as above, storing on the internal flash is actually much slower, and the whole process usually takes more than 2s. Next startups are however much faster, since we don't need to do that again. We should however do that extraction step after startup. After that, the dynamic linker then needs to apply 200000 relocations to data segments. If I recall correctly, this step takes somewhere between 100 and 200ms for each of the processes. I filed a bug quite some time ago to avoid these relocations in the child process (651890) when possible (when the base address where the library is loaded is the same), but it's tricky in the current state of our dynamic linker. Mike
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mike Hommey |
8/24/11 12:12 AM |
On Wed, Aug 24, 2011 at 08:46:25AM +0200, Mike Hommey wrote: > On Tue, Aug 23, 2011 at 06:47:13PM -0700, David Mandelin wrote: > > On 8/22/2011 10:35 PM, Mike Hommey wrote: > > > On Mon, Aug 22, 2011 at 06:18:33PM -0700, David Mandelin wrote: > > >> - 0.5s XUL reflows > > >> - 0.5s sqlite IO (150-1000ms, avg 500) > > >> - ~0.5s linker badness (needs linker improvements) > > > That's actually more like 0.8 to 1s when you don't have enough space on > > > your device, and ~0.3s when you do. Though the first start is then > > > abysmal, as writing the decompressed files usually takes more than 2s. > > > We should delay that decompression. Speaking of the first start, > > > creating the profile is also taking a whole lot of time, and really > > > doesn't help making a first good impression. > > > > I must confess I don't actually know what the linker badness really is. > > Do we have a bug on file for that, or could you provide a quick > > description for those of us not in the know. > > As our binary footprint is much more than the 12~13MB of the apk, having > the apk uncompressed on the system filesystem can be eating a lot of its > resources on small devices. So, when we detect there is not enough space > in the system filesystem for our files, we uncompress our binaries at > startup, in memory (ashmem, to be precise). Uncompressing takes around > 600~700ms on a Nexus S. The easiest way to get that down is to > uncompress less things, which is not that easy when you basically have > one file that represents 87% of what you uncompress. Another way could be to find a maybe slightly less efficient but much faster compression algorithm. Mike
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Martijn |
8/24/11 12:34 AM |
On Wed, Aug 24, 2011 at 5:17 AM, Joe Drew <j...@mozilla.com> wrote: > > On 2011-08-23 9:45 PM, David Mandelin wrote: >>> >>> We'll soon replace the current 4fps throbber with a much smoother one >>> that is two-state (like desktop Firefox) to provide better perceived >>> smoothness and better feedback on the loading process: >>> >>> https://bugzilla.mozilla.org/show_bug.cgi?id=679927 >>
>> But why not a full progress bar? Pageload times were 2-20s in my >> tests--if I'm going to wait 10s I'd like to see a growing bar, not just >> a throbber. >
> Progress bars don't really make sense on the web, unfortunately. While you > can tell how long your first resource load (i.e., the page) will take > (usually), there's absolutely no way to know ahead of time how big each of > the subsequent resource loads will be. This means that the progress bar will > either jump around or stall for long periods of time. > > For example, imagine a page that has, as its last part of markup, <img > src="somebigimage.png" /> - a 4 MB image. The rest of the page is 1 kB. The > browser originally thought it was 99% finished loading, but it has suddenly > discovered it is actually less than 1% finished loading. What is a good > progress bar presentation for this situation? >From a technnical point of view, it might not make sense, but I think that it makes sense from a user point of view. Often, when I'm forced to look at a blank page waiting it to get loaded, a progress bar keeps me informed that at least something is progressing, while a throbber doesn't give me that information. Regards, Martijn > AIUI from discussions with Beltzner, this is one of several reasons the > progress bar was removed from desktop Firefox. > > Joe
> _______________________________________________ > dev-planning mailing list > dev-pl...@lists.mozilla.org> https://lists.mozilla.org/listinfo/dev-planning> -- Martijn Wargers - Help Mozilla! http://quality.mozilla.org/ http://wiki.mozilla.org/Mozilla_QA_Community irc://irc.mozilla.org/qa - /nick mw22
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Gervase Markham |
8/24/11 2:39 AM |
On 24/08/11 02:58, David Mandelin wrote: > - Opera Mobile was slow and smooth > - Stock was fast and jerky > - Firefox was very fast and checkerboardy > > Fast, smooth, no checkerboards: pick 2. Use the page background colour to fill, and have all three? Gerv
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Gervase Markham |
8/24/11 2:39 AM |
On 23/08/11 15:26, Robert Kaiser wrote: > 1) We don't have any good support for embedding Gecko in native apps > right now, we'd need to build that from scratch - and we would make it > impossible to use this frontend on any other mobile system or run Fennec > on desktop for testing the way we do now if we go with a Android-native > interface. It also would kill a lot of possibilities of add-ons. Also, if and when we port to iPhone, WP7 etc., we'd need to write a new UI for each of them. Or, to put it another way, this additional requirement might make the difference between us being able to get stood up quickly on new platforms, and every new platform being a significant up-front effort. Gerv
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
James May |
8/24/11 4:26 AM |
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Patrick McManus |
8/24/11 6:16 AM |
On Tue, 2011-08-23 at 23:17 -0400, Joe Drew wrote: > Progress bars don't really make sense on the web, unfortunately. While > you can tell how long your first resource load (i.e., the page) will > take (usually), there's absolutely no way to know ahead of time how big > each of the subsequent resource loads will be. This means that the > progress bar will either jump around or stall for long periods of time. > > For example, imagine a page that has, as its last part of markup, <img > src="somebigimage.png" /> - a 4 MB image. The rest of the page is 1 kB. > The browser originally thought it was 99% finished loading, but it has > suddenly discovered it is actually less than 1% finished loading. What > is a good progress bar presentation for this situation? > forgive the digression into severely forward looking statements, but I've got SPDY on the brain lately and this is something it can help with. HTTP forces us to queue our requests, beyond the first few that we do in parallel, leading to the lack of visibility into the total number of bytes left to download in that queue, as you describe. But SPDY lets us send all of those requests in parallel while still giving the lion's share of the bandwidth to the high priority ones (html, css, js), but letting the response headers and first few bytes of the images trickle in without them getting queued behind the total data transfer. We can use that information to figure out the total progress bar size (as well as the actual geometry of the images for layout, etc..) much earlier than with HTTP. |
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mike Hommey |
8/24/11 6:19 AM |
That doesn't change much. You still need to fetch the HTML file before knowing what CSS, JS, images you will need for it. And for each of these dependencies, new dependencies can pop up once you read them. Mike
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Robert Accettura |
8/24/11 6:32 AM |
True, but I don't think a browser doesn't need to parse the entire HTML file before starting to fetch. CSS and JS typically are referenced in the <head/> which is likely in the first 20% of the html payload even on a mobile site. -R
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Patrick McManus |
8/24/11 6:38 AM |
On Wed, 2011-08-24 at 15:19 +0200, Mike Hommey wrote: > That doesn't change much. You still need to fetch the HTML file before > knowing what CSS, JS, images you will need for it. And for each of these > dependencies, new dependencies can pop up once you read them. Of course. But the glut of media bytes is what currently dominates and blocks the queue and that problem is removed as a head of line blocker. It doesn't solve anything completely, but I suspect it helps a lot. According to http://code.google.com/speed/articles/web-metrics.html the average page is 320KB, of 12% which is html, 64% is images, 18% is script, and 6% is stylesheet. |
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Robert Kaiser |
8/24/11 6:47 AM |
Mark Finkle schrieb: > I can't see using HTML to replace XUL until we have XBL2 (or simialr) to > create reusable bindings for widgets. I, for one, am not interested in > building applications using <ul> and <li> and clumsy wrappers for JS and > event encapsulation. I agree, but I see this as a perfect opportunity to finally get some push behind such a technology like XBL2 to drive it to a working and usable implementation. We have been lagging in that and other means of driving HTML to measure up with XUL in terms of UI design mostly because we are already using XUL and have something that works for us. That leaves web apps in the cold and makes us base our own work as well as our add-ons story on web-like but still proprietary technology. We need to change that and push hard for that change. Robert Kaiser -- Note that any statements of mine - no matter how passionate - are never meant to be offensive but very often as food for thought or possible arguments that we as a community should think about. And most of the time, I even appreciate irony and fun! :)
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Robert Kaiser |
8/24/11 6:49 AM |
Boris Zbarsky schrieb: > On 8/23/11 2:31 PM, Boris Zbarsky wrote: >>> That should be a very short patch to try... >> >> Maybe. XUL parsing differs from normal XML parsing (e.g. in its >> whitespace handling) so there could be all sorts of glitches when >> actually doing this if scripts assume things about indexing. > > Also, the whole overlay system is tied to XULDocument, so wouldn't work > when an XHTML document is used. Argh, yes, HTML is badly missing something like the overlay system. Any way to get something in that style into HTML? Robert Kaiser -- Note that any statements of mine - no matter how passionate - are never meant to be offensive but very often as food for thought or possible arguments that we as a community should think about. And most of the time, I even appreciate irony and fun! :)
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mike Hommey |
8/24/11 6:55 AM |
On Wed, Aug 24, 2011 at 09:32:16AM -0400, Robert Accettura wrote: > True, but I don't think a browser doesn't need to parse the entire > HTML file before starting to fetch. CSS and JS typically are > referenced in the <head/> which is likely in the first 20% of the html > payload even on a mobile site. I think we do. Don't we? Mike
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mike Shaver |
8/24/11 7:04 AM |
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Robert Kaiser |
8/24/11 7:13 AM |
David Mandelin schrieb: > The add-on question is difficult. I don't know a lot about it, but I was > vaguely hoping that we could provide a good subset of the add-on API > (APIs?) on top of a new architecture. AFAIK, even the SDK- or Jetpack-based add-ons heavily rely on having the ability of DOM manipulations and HTML-based UI controls. Robert Kaiser -- Note that any statements of mine - no matter how passionate - are never meant to be offensive but very often as food for thought or possible arguments that we as a community should think about. And most of the time, I even appreciate irony and fun! :)
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Robert Accettura |
8/24/11 7:28 AM |
Which makes me think SPDY would have a decent impact, assuming a reasonable effort was made by the web developer. Markup tends to bloat, especially when you have legacy systems around. Web Developers don't always have the level of control one would like.
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Kadir Topal |
8/24/11 9:17 AM |
Mark Finkle schrieb: > On 08/23/2011 08:31 PM, Kadir Topal wrote: >> >> >> Mark Finkle schrieb: > >>> I am less worried about getting from 5s to 2s. I am more worried about >>> 10s (or greater) startup times. If we get additional speedups and get to >>> 2s, great - but if the majority of users are still taking ~10s, we still >>> lose. >> >> This one I don't agree with. If Firefox takes 5 seconds to load and the >> stock browser takes 1.5 seconds, I'm not going to use Firefox. On my >> mobile I usually need Firefox to quickly check something, so 2 or 5 >> seconds can be the difference between make and break. > > I agree, but my point is: If we see 5s startup times now, but many other > people still see >10s startup times, getting the fastest startup to 2s > doesn't matter if many people still see ~10s startups. > > Just because 20% of our users see fast startup times mean nothing if the > majority still see slow startup times. We need to figure out why all of > our users are not seeing ~5s startup times right now. > > In fact, I remember you filed a bug about horrible startup times > yourself. No one else could reproduce the slow startup you were > experiencing. Yes, but what I mean is: Getting everyone to 5 seconds will not help. I'd still not consider using Firefox, if it takes 5 seconds to load and the stock browser takes only 2. In this case it doesn't really matter if it's 5 or 10 seconds, as long as I feel it's considerably slower than the stock browser to start up. So shooting for anything less than parity with stock browser is a loosing proposition IMHO. -Kadir
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Michael Verdi |
8/24/11 9:20 AM |
David Mandelin wrote: > > Secondary Goals: > > B5. Improve startup time. > > B6. Improve pageload time. > Personally, I think these should be the #1 priority. Like the, stop everything and fix this kind of number one. The vast majority of my interactions with a browser on my phone is following a link from email, twitter, facebook or any number of apps (may be the case for many users too http://mzl.la/n2omLK ). If Firefox has to cold start it's painful. And the thing is, it has to cold start all of the time. I can't tell you how many times a day I see that logo (6? 8?). It's making me start to hate the logo. Here's a quick comparison that I did on my HTC Desire HD. I follow a link to a blog from twitter. I quit both browsers before doing the test. As a bonus you get to see that when I do get the page loaded the default tap-to-zoom on Firefox is not much help. http://people.mozilla.org/~mverdi/video/mobile-comparison.webm- Michael -- I work on support irc: verdi |
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mike Hommey |
8/24/11 9:48 AM |
There is absolutely no way we can get as fast as the "native" browser, and here is why: *all* android applications effectively embed webkit, which is the main part of the native browser. Yes, that includes Firefox. It also means webkit is effectively very unlikely to be paged out, i.e. webkit never cold starts. Mike
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Michael Verdi |
8/24/11 10:13 AM |
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mike Hommey |
8/24/11 10:21 AM |
We can and we must do better than the current state. I'm just saying that it's futile to set "as fast as native browser" as a goal, it's just impossible to reach. Mike
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mike Hommey |
8/24/11 10:22 AM |
(for cold startup, that is) Mike
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Michael Verdi |
8/24/11 10:42 AM |
Well maybe some combination of as fast a cold startup as possible and cold startups being super rare could lessen this pain. But without eliminating it, why shouldn't the mainstream user just use Dolphin browser if they want extra features? Because it uses the built-in webkit, its just as fast as the native browser and supports Flash. The biggest complaints, by far, of Android users that have tried Firefox is that it doesn't support Flash and it's slow. Until that changes, it may not matter how awesome everything else is. I LOVE sync on my mobile and, as a former iPhone user, I'm fine without Flash but more often than not, Firefox's slowness drives me crazy. - Michael |
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Joel Stover |
8/24/11 11:24 AM |
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Ron Hunter |
8/24/11 11:48 AM |
You should consider that the 'stock browser' for Windows is IE, which is loading ONLY the GUI, as much of the base code is 'resident'. A lot depends on such things as how much RAM you have, and how fast your HD is, and how long it has been since it was defragmented. All of which is way beyond the control of Mozilla. |
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Ron Hunter |
8/24/11 11:51 AM |
Hummm. Maybe Android can be talked into keeping much of Firefox resident like the 'stock browser', and like Windows keeps most of IE resident. Stock browsers have the advantage on ALL systems, it seems. |
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Kadir Topal |
8/24/11 12:04 PM |
Ron Hunter schrieb: On my desktop I don't really care about a second or two, because I usually use the browser for an extended period of time. On my mobile on the other hand, I'm usually quickly checking something, the dynamics are completely different and so is my patience. -Kadir
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Steve Fink |
8/24/11 12:54 PM |
On 08/23/2011 08:38 PM, Joe Drew wrote: > > On 2011-08-23 11:32 PM, Benjamin Stover wrote: >> I think one of the things we're going to need is something like >> about:memory, that allows people to get a timeline of exactly what is >> slow in their startup path for those worst cases. > > Yes. Bootchart, as mentioned in the LWN link in my original post, was > essential in making up a startup time budget. We should use it, or > something like it, and make sure it's built in to everybody's Firefox. > And then we should allocate all our subsystems N ms to start up (on a > given piece of hardware), and make that happen. > >> Maybe we could adjust >> function timers to be much faster and enable them by default. > > IIRC, function timers were totally removed - please correct me if I'm > wrong. Maybe you're thinking of the timeline, which was indeed removed - https://bugzilla.mozilla.org/show_bug.cgi?id=579571 |
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mark Finkle |
8/24/11 1:22 PM |
On 08/22/2011 09:18 PM, David Mandelin wrote: > I had assumed that stock was faster because it used special tricks to > get pre-started, and so there was not much we could do (taking Opera's > similar score as evidence we are about as good as we can be). But Taras > says that we should be able to get down to 2s on his Galaxy S. He listed > these items as wasted time in startup: Most of the WebKit library is probably already loaded in memory, so there is a bit of a "trick" > I also tested clicking the app icon when the browser is already open > (maybe this is "warm startup"--not sure what the right term is). I found > that stock is the fastest, with almost no delay, Opera Mobile has a > delay, and Firefox is clearly the slowest. So that area needs help too. This is an area where memory usage comes inot play as well. When an application goes into the background on Android, the OS will kill it if more memory is needed for other tasks. Currently, Fennec will fire a "memory-pressure" notification which should trigger various places in the platform to release caches and free up memory. If we can make sure that Gecko is releasing as much cached memory as is reasonable to do, we might be able to avoid the dreaded OOM killer. That would mean switching back to Fennec would be much faster, and mot require reloading the application and any session data. more details: https://bugzilla.mozilla.org/show_bug.cgi?id=675259
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Boris Zbarsky |
8/24/11 2:15 PM |
On 8/24/11 4:22 PM, Mark Finkle wrote: > This is an area where memory usage comes inot play as well. When an > application goes into the background on Android, the OS will kill it if > more memory is needed for other tasks. Currently, Fennec will fire a > "memory-pressure" notification which should trigger various places in > the platform to release caches and free up memory. Do we have any data on how our memory usage changes when this happens? Do we drop jit data on memory pressure, and if not, is there a bug on it yet? -Boris
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Ron Hunter |
8/24/11 2:30 PM |
You should be using my old Windows 6.3 smart?phone. Takes about 15 seconds to load ANYTHING. Only thing that loads reasonably fast is Opera Mini. New phone in December. Looking for a dual core 1Ghz machine. Probably won't be able to afford an iPhone 5. |
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mark Finkle |
8/24/11 4:00 PM |
On 08/24/2011 05:15 PM, Boris Zbarsky wrote: > On 8/24/11 4:22 PM, Mark Finkle wrote: >> This is an area where memory usage comes inot play as well. When an >> application goes into the background on Android, the OS will kill it if >> more memory is needed for other tasks. Currently, Fennec will fire a >> "memory-pressure" notification which should trigger various places in >> the platform to release caches and free up memory. > > Do we have any data on how our memory usage changes when this happens? Not yet > > Do we drop jit data on memory pressure, and if not, is there a bug on it > yet? I see some support for "memory-pressure", but it seems to cycle collect and do a GC. It doesnt' seem to empty the JIT cache. Unless onelof those two operations will do it. http://mxr.mozilla.org/mozilla-central/source/dom/base/nsJSEnvironment.cpp#192 I can file a bug
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mark Finkle |
8/24/11 4:08 PM |
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
David Mandelin |
8/24/11 6:55 PM |
On 8/23/2011 8:02 PM, L. David Baron wrote: > On Tuesday 2011-08-23 18:36 -0700, David Mandelin wrote: >> This ties in to another idea I had for mobile. I get the impression that >> fully general HTML layout is slow on mobile. After all, the typical >> device-power/content-complexity ratio was much different when HTML and >> CSS were designed. So: >> >> Can we create extensions for HTML that support cheap (in time and >> energy) layout of mobile apps? Maybe an XBL2-type thing, but with the >> intent of having it work for mobile content as well, and eventually >> getting it into the (HTML or other appropriate) standards? > > The desktop computers we used when HTML and CSS were designed were > considerably less powerful than today's mobile phones. It's just > that content complexity has gone up in proportion to what's > tolerable on desktops, and mobiles are behind desktops. Yes. > I think many of today's sites use an excessive amount of HTML and > CSS for what they're trying to accomplish, though (often because > they're using a bunch of frameworks in the middle each of which adds > a bunch of complexity). So there is some hope that designers will slim things down for mobile. I guess there will have to be some adaptations. Maybe we should start working with a bunch of mobile site designers to learn more about where they are going? > I think that's best fixed by providing layout primitives that better > match what authors want to accomplish, so they can use those > primitives more directly rather than putting a bunch of layers of > abstraction in between. I don't think they need to be more > efficient than today's primitives, though they probably do need to > be similar in efficiency. That sounds about right. Dave
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
David Mandelin |
8/24/11 6:59 PM |
On 8/23/2011 8:17 PM, Joe Drew wrote: > > On 2011-08-23 9:45 PM, David Mandelin wrote: >>> We'll soon replace the current 4fps throbber with a much smoother one >>> that is two-state (like desktop Firefox) to provide better perceived >>> smoothness and better feedback on the loading process: >>> >>> https://bugzilla.mozilla.org/show_bug.cgi?id=679927>> >> But why not a full progress bar? Pageload times were 2-20s in my >> tests--if I'm going to wait 10s I'd like to see a growing bar, not just >> a throbber. > > Progress bars don't really make sense on the web, unfortunately. That is a surprising statement to me. This is simply from my perspective as a user. When I use Opera Mobile, it gives me a progress bar that makes it seem like stuff is happening and I'm getting somewhere. With Firefox for Android, I get a rather unattractive gray thing that slowly moves in a circle. That makes me feel like I'm slowly going in circles, with no endpoint in sight. > While > you can tell how long your first resource load (i.e., the page) will > take (usually), there's absolutely no way to know ahead of time how big > each of the subsequent resource loads will be. This means that the > progress bar will either jump around or stall for long periods of time. Sure, that's the engineering view. But the progress bar isn't being used for engineering measurements, it's to reduce the pain the user feels when waiting. > For example, imagine a page that has, as its last part of markup, <img > src="somebigimage.png" /> - a 4 MB image. The rest of the page is 1 kB. > The browser originally thought it was 99% finished loading, but it has > suddenly discovered it is actually less than 1% finished loading. What > is a good progress bar presentation for this situation? Dunno. But I'm not that worried about worst-case accuracy scenarios here. > AIUI from discussions with Beltzner, this is one of several reasons the > progress bar was removed from desktop Firefox. That's desktop. Dave
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
David Mandelin |
8/24/11 7:07 PM |
Great video. And you reminded me of something: I set those links to use the stock browser because the Firefox startup experience was intolerable. Dave
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mark Finkle |
8/24/11 7:16 PM |
This sounds too much like WML for me to take too seriously. Web developers will continue to create mobile web sites using standard web libraries and techniques. I don't think we can create a movement to use different primitives for mobile web sites. If you're going to create new primitives, make them work for the entire web.
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
David Mandelin |
8/24/11 7:20 PM |
On 8/23/2011 10:20 PM, Wesley Johnston wrote: >> I think I agree, but I'm not sure yet. Opera has a feature where if you >> scroll fast, they show a button with an up or down arrow that will >> scroll you all the way, which I thought was just generally neat, but >> they might also have added it to mitigate their slower scrolling. > > We actually have a feature in Fennec where two finger up or down swipes > will take you to the top and bottom of documents (left and right move back > and forward in history), Hey, cool! I've been wanting some feature that did that, and I didn't know we had that. Do our users know? How do we teach them? > and will usually show checkerboard for a half > second or so while we draw. I can see that very clearly on boingboing. > The other day my wife was complaining about > checkerboarding and I realized that she was unintentionally two finger > swiping and didn't understand what was going on. So some of these > probably fall in the category of things we could do more slowly, but > with better perceived performance (bugs 641816 and 653092). Or just give 'em something better than a checkerboard to look at for half a second. > We have a few other simple fixes that should help panning lying around, > but like has been said, we don't have any metrics that really > let us know if they are actually helping or not. Just people > saying, "I like this one!". I'm working with stechz to get the tools > we need, and some simple tests written. I'm going to try and get that > up in bug 607777 soon. I think the subjective response is ultimately the only one that matters. Automation is always nice, but I think it's helpful only if it (at least dimly) reflects the subjective experience. Dave
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
L. David Baron |
8/24/11 7:39 PM |
On Wednesday 2011-08-24 22:16 -0400, Mark Finkle wrote: > This sounds too much like WML for me to take too seriously. Web > developers will continue to create mobile web sites using standard > web libraries and techniques. I don't think we can create a movement > to use different primitives for mobile web sites. If you're going to > create new primitives, make them work for the entire web. That's the idea; I wasn't suggesting anything mobile-only. -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla Corporation http://www.mozilla.com/ 𝄂
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Robert O'Callahan |
8/24/11 10:40 PM |
If following links is super-common, maybe we could optimize for that explicitly by getting just that page up and loading browser chrome later. On Aug 25, 2011 4:21 AM, "Michael Verdi" <mve...@mozilla.com> wrote: > David Mandelin wrote: >> >> Secondary Goals: >> >> B5. Improve startup time. >> >> B6. Improve pageload time. >> > Personally, I think these should be the #1 priority. Like the, stop > everything and fix this kind of number one. The vast majority of my > interactions with a browser on my phone is following a link from email, > twitter, facebook or any number of apps (may be the case for many users > too http://mzl.la/n2omLK ). If Firefox has to cold start it's painful. > And the thing is, it has to cold start all of the time. I can't tell you > how many times a day I see that logo (6? 8?). It's making me start to > hate the logo. Here's a quick comparison that I did on my HTC Desire HD. > I follow a link to a blog from twitter. I quit both browsers before > doing the test. As a bonus you get to see that when I do get the page > loaded the default tap-to-zoom on Firefox is not much help. > http://people.mozilla.org/~mverdi/video/mobile-comparison.webm >
> - Michael > > -- > I work on support > irc: verdi >
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mike Hommey |
8/24/11 11:01 PM |
On Thu, Aug 25, 2011 at 05:40:59PM +1200, Robert O'Callahan wrote: > If following links is super-common, maybe we could optimize for that > explicitly by getting just that page up and loading browser chrome later. That's a very good idea. And the browser chrome can be initialized while the page is being downloaded. Mike
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mike Hommey |
8/24/11 11:11 PM |
On Wed, Aug 24, 2011 at 11:20:34AM -0500, Michael Verdi wrote: > David Mandelin wrote: > > > >Secondary Goals: > > > >B5. Improve startup time. > > > >B6. Improve pageload time. > > > Personally, I think these should be the #1 priority. Like the, stop > everything and fix this kind of number one. The vast majority of my > interactions with a browser on my phone is following a link from > email, twitter, facebook or any number of apps (may be the case for > many users too http://mzl.la/n2omLK ). If Firefox has to cold start > it's painful. And the thing is, it has to cold start all of the > time. I can't tell you how many times a day I see that logo (6? 8?). > It's making me start to hate the logo. Here's a quick comparison > that I did on my HTC Desire HD. I follow a link to a blog from > twitter. I quit both browsers before doing the test. As a bonus you > get to see that when I do get the page loaded the default > tap-to-zoom on Firefox is not much help. > http://people.mozilla.org/~mverdi/video/mobile-comparison.webm One thing to note: Assuming the browsers start loading the url when they display it, Stock browser starts at 1.0, Firefox starts at 4.1. Then Stock browser stops at 7.5 while Firefox stops at 16.9. That's 6.5s to load and display the page on Stock browser vs. 12.8 for Firefox. Almost two-fold. (though Firefox starts displaying something at 14, but that's still much slower than stock that starts displaying at 4.8) Another thing to note: The Firefox url bar changes from the t.co address to the page title at 7.1. That's 3 seconds after showing the UI. That suggests waiting for the redirection from t.co is taking a whole lot of time. Stock browser switches to loading bitchmagazine.org at 1.4, that's 0.4s after showing the UI. Mike
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Gervase Markham |
8/25/11 3:38 AM |
On 25/08/11 06:40, Robert O'Callahan wrote: > If following links is super-common, maybe we could optimize for that > explicitly by getting just that page up and loading browser chrome later. That's a really interesting idea. Is there any speed value at all in just loading the web page full screen (no URL bar, no sides) at start-up, and then loading the chrome when the page has loaded? I bet it's not trivial to achieve, though... Gerv |
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Robert Kaiser |
8/25/11 6:30 AM |
Ron Hunter schrieb: > You should consider that the 'stock browser' for Windows is IE,
We are talking about mobile devices here, and more specifically, about Android. I didn't know that was the same as Windows and IE. Robert Kaiser -- Note that any statements of mine - no matter how passionate - are never meant to be offensive but very often as food for thought or possible arguments that we as a community should think about. And most of the time, I even appreciate irony and fun! :)
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Robert Kaiser |
8/25/11 6:34 AM |
David Mandelin schrieb: > Unless specified otherwise, all numbers for Firefox are for Firefox 6 on > my Atrix. I've just updated the version on my N900 from a Aug 02 (8.0a1) Nightly to a current (9.0a1) Nightly, and it feels like a significant jump in performance to me. I know from 6 to 8, we improved, and this month, we seem to have done even more. As our primary focus is not my old maemo5 device but Android, I'd expect the effects to be even larger there - have you tested what difference you feel on your side there? Robert Kaiser -- Note that any statements of mine - no matter how passionate - are never meant to be offensive but very often as food for thought or possible arguments that we as a community should think about. And most of the time, I even appreciate irony and fun! :)
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
David Tenser |
8/25/11 6:59 AM |
On 2011-08-24 18:20, Michael Verdi wrote: > David Mandelin wrote: >> >> Secondary Goals: >> >> B5. Improve startup time. >> >> B6. Improve pageload time. >> > Personally, I think these should be the #1 priority. Like the, stop > everything and fix this kind of number one. The vast majority of my > interactions with a browser on my phone is following a link from email, > twitter, facebook or any number of apps (may be the case for many users > too http://mzl.la/n2omLK ). If Firefox has to cold start it's painful. > And the thing is, it has to cold start all of the time. I can't tell you > how many times a day I see that logo (6? 8?). It's making me start to > hate the logo. Here's a quick comparison that I did on my HTC Desire HD. > I follow a link to a blog from twitter. I quit both browsers before > doing the test. As a bonus you get to see that when I do get the page > loaded the default tap-to-zoom on Firefox is not much help. > http://people.mozilla.org/~mverdi/video/mobile-comparison.webm Really good video that summarizes two of the main issues I see with Fennec today. Although speed improvements are critical and will to some extent get better as hardware becomes faster, a far more Fennec-specific issue is the way zooming is handled. As can be seen on this video, you can't actually read the text on a stock Fennec install.
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Matt Brubeck |
8/25/11 7:11 AM |
On 08/24/2011 10:40 PM, Robert O'Callahan wrote: > If following links is super-common, maybe we could optimize for that > explicitly by getting just that page up and loading browser chrome later. We already do this to some extent; we wait until the first page load completes and then fire a "UIReadyDelayed" event. Much of our chrome initialization starts at that event. If you try to open the preference panels before that first page load is done, you can actually watch them initialize. Our mobile Ts benchmark measures the time to the end of the first page load. Delaying chrome initialization is one of the main ways we've improved performance on that benchmark.
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mark Finkle |
8/25/11 7:15 AM |
On 08/25/2011 09:59 AM, David Tenser wrote: > On 2011-08-24 18:20, Michael Verdi wrote: >> Personally, I think these should be the #1 priority. Like the, stop >> everything and fix this kind of number one. The vast majority of my >> interactions with a browser on my phone is following a link from email, >> twitter, facebook or any number of apps (may be the case for many users >> too http://mzl.la/n2omLK ). If Firefox has to cold start it's painful. >> And the thing is, it has to cold start all of the time. I can't tell you >> how many times a day I see that logo (6? 8?). It's making me start to >> hate the logo. Here's a quick comparison that I did on my HTC Desire HD. >> I follow a link to a blog from twitter. I quit both browsers before >> doing the test. As a bonus you get to see that when I do get the page >> loaded the default tap-to-zoom on Firefox is not much help. >> http://people.mozilla.org/~mverdi/video/mobile-comparison.webm > > Really good video that summarizes two of the main issues I see with > Fennec today. Although speed improvements are critical and will to some > extent get better as hardware becomes faster, a far more Fennec-specific > issue is the way zooming is handled. As can be seen on this video, you > can't actually read the text on a stock Fennec install. Work is happening to improve this. Watch this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=627842
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mark Finkle |
8/25/11 7:28 AM |
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Asa Dotzler |
8/25/11 8:07 AM |
David Tenser wrote: > Really good video that summarizes two of the main issues I see with > Fennec today. Although speed improvements are critical and will to some > extent get better as hardware becomes faster, a far more Fennec-specific > issue is the way zooming is handled. As can be seen on this video, you > can't actually read the text on a stock Fennec install. I don't use smartphones so I can't comment much about the readability issues there but I don't find the zoom thing to be any barrier to using Fennec on tablet with decent resolution. - A
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mike Hommey |
8/25/11 8:32 AM |
On Thu, Aug 25, 2011 at 10:28:11AM -0400, Mark Finkle wrote: > On 08/25/2011 10:11 AM, Matt Brubeck wrote: > >On 08/24/2011 10:40 PM, Robert O'Callahan wrote: > >>If following links is super-common, maybe we could optimize for that > >>explicitly by getting just that page up and loading browser chrome later. > > > >We already do this to some extent; we wait until the first page load > >completes and then fire a "UIReadyDelayed" event. Much of our chrome > >initialization starts at that event. If you try to open the preference > >panels before that first page load is done, you can actually watch them > >initialize. > > > >Our mobile Ts benchmark measures the time to the end of the first page > >load. Delaying chrome initialization is one of the main ways we've > >improved performance on that benchmark. > > Building on what Matt talks about, we do have some data on startup > time in the field. Firefox (desktop and mobile) send some startup > time performance data to AMO along with the daily add-ons ping. > Mozilla uses that to gauge the affect of add-ons on startup time. > > For mobile, we can use it to get an idea of the range of startup > times happening in the field. I did a post using the data back in Fx > 4 timeframe: > http://starkravingfinkle.org/blog/2011/02/firefox-4-for-mobile-beta-5-performance-improvements/ > > I pulled the latest graphs for Fx7: > http://people.mozilla.com/~mfinkle/fennec/startup-time-general-7.0.png > http://people.mozilla.com/~mfinkle/fennec/startup-time-median-7.0.png What does the second graph represent on the horizontal axis? > You can see we have improved a bit since Fx4, but the range of > startup times is still fairly poor and should be improved. Ben > Stover's StartupShrink project has come up with a few mini project > ideas. It however raises a question: is the improvement for the most on our part, or for the most because more and more of our users are using faster devices? Mike
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mark Finkle |
8/25/11 8:35 AM |
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mike Hommey |
8/25/11 8:47 AM |
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mark Finkle |
8/25/11 10:07 AM |
On 08/25/2011 11:47 AM, Mike Hommey wrote: >> Time. Each version of Firefox sends data each day. So what you see >> is daily data collected for Firefox 7. > > So that's 4 days worth? with tMain improvements every day ? 4 days worth of Firefox 7 for Mobile data. Just normal variances in data because of population changes.
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Michelle Luna |
8/25/11 10:46 AM |
On 8/24/11 7:20 PM, David Mandelin wrote: > On 8/23/2011 10:20 PM, Wesley Johnston wrote: >>> I think I agree, but I'm not sure yet. Opera has a feature where if you >>> scroll fast, they show a button with an up or down arrow that will >>> scroll you all the way, which I thought was just generally neat, but >>> they might also have added it to mitigate their slower scrolling. >> We actually have a feature in Fennec where two finger up or down swipes >> will take you to the top and bottom of documents (left and right move back >> and forward in history), > Hey, cool! I've been wanting some feature that did that, and I didn't > know we had that. Do our users know? How do we teach them? >
One great way to teach users about new features is to create or update an article on SUMO. I've added a draft article for using gestures on mobile here: https://support.mozilla.com/en-US/kb/how-do-i-use-firefox-gestures-my-mobile-device/revision/16681Just register and then edit the wiki any time you have a solution you want to document or improve. On the larger topic of performance, we also need an article for the short-term to help folks sort out why Firefox for Mobile is slow, so I started a troubleshooting article for that problem here: https://support.mozilla.com/en-US/kb/why-firefox-mobile-slow/revision/16686 Let me know what you think. Thanks, Michelle Luna Firefox for Mobile Support http://www.meetup.com/Firefox-Android-superheroes/
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Steve Fink |
8/25/11 11:13 AM |
On 08/25/2011 07:28 AM, Mark Finkle wrote: > On 08/25/2011 10:11 AM, Matt Brubeck wrote: >> On 08/24/2011 10:40 PM, Robert O'Callahan wrote: >>> If following links is super-common, maybe we could optimize for that >>> explicitly by getting just that page up and loading browser chrome >>> later. >> >> We already do this to some extent; we wait until the first page load >> completes and then fire a "UIReadyDelayed" event. Much of our chrome >> initialization starts at that event. If you try to open the preference >> panels before that first page load is done, you can actually watch them >> initialize. >> >> Our mobile Ts benchmark measures the time to the end of the first page >> load. Delaying chrome initialization is one of the main ways we've >> improved performance on that benchmark. > > Building on what Matt talks about, we do have some data on startup > time in the field. Firefox (desktop and mobile) send some startup time > performance data to AMO along with the daily add-ons ping. Mozilla > uses that to gauge the affect of add-ons on startup time. Do you get information about memory installed or CPU? It'd be interesting to see a scatterplot of memory vs startup time. (Maybe available memory at the time Firefox is launched? Is that collectible, or perhaps not meaningful because it'll trigger memory-pressure events to all other apps?) |
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mark Finkle |
8/25/11 1:10 PM |
On 08/25/2011 02:13 PM, Steve Fink wrote: > On 08/25/2011 07:28 AM, Mark Finkle wrote: >> Building on what Matt talks about, we do have some data on startup >> time in the field. Firefox (desktop and mobile) send some startup time >> performance data to AMO along with the daily add-ons ping. Mozilla >> uses that to gauge the affect of add-ons on startup time. > > Do you get information about memory installed or CPU? It'd be > interesting to see a scatterplot of memory vs startup time. (Maybe > available memory at the time Firefox is launched? Is that collectible, > or perhaps not meaningful because it'll trigger memory-pressure events > to all other apps?) The AMO pings do not get the device data, but Zippity (http://zippityserver.appspot.com) and Telemetry do. We do not send "installed RAM", but using the device ID we could create a lookup.
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mark Finkle |
8/25/11 1:55 PM |
On 08/22/2011 09:18 PM, David Mandelin wrote: > I've been thinking a bit about what can do, and what we need to do, for > Firefox performance on mobile devices. This is really just a start, but > I think it points the way for the performance efforts we have to make to > make Firefox just as great on Android/ARM as it is on desktop. I give an > evaluation of performance today, recommendations for top performance > goals, some big changes we might need, and last, a draft plan, really > just a sketch, of the way forward. I'd like to propose that Mozilla changes the way we develop the platform. Instead of developing platform changes first on desktop and then trickling down to mobile, we should reverse that. We should have all platform development happen first using mobile hardware (tablets and phones). So all initial coding, profiling and debugging happens on mobile. Once the code passes the quality and performance levels needed for mobile, we can then get desktop implementations ready (where separate desktop impls are actually needed). That might help with situations where features land and work well on desktop, but don't really meet expectations on mobile. Currently, we would file a bug to get the platform devs to try to improve the situation on mobile. Most of the time, the platform devs _do_ try get fixes for mobile, but sometimes we don't get a fix landed in a timely manner, if at all. There are improve-for-mobile bugs currently waiting for dev resources. I propose the Mobile First idea for the entire platform development team and not just create smaller subset teams to focus on mobile. I focus on the platform team, but other teams should also adopt the strategy too. Desktop and Mobile Firefox have front-end teams that focus on UI for the respective products. I'm not sure how a Mobile First approach would affect those teams. Thoughts?
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Jonathan Kew |
8/25/11 2:11 PM |
On 25 Aug 2011, at 21:55, Mark Finkle wrote: > I'd like to propose that Mozilla changes the way we develop the platform. Instead of developing platform changes first on desktop and then trickling down to mobile, we should reverse that. > > We should have all platform development happen first using mobile hardware (tablets and phones). So all initial coding, profiling and debugging happens on mobile. Once the code passes the quality and performance levels needed for mobile, we can then get desktop implementations ready (where separate desktop impls are actually needed). Interesting approach! Offhand, I do have a couple reservations, though... Are the mobile development tools (coding and debugging environments, profiling tools, etc) really up to the level where we could do this without seriously impacting developer productivity? Also, I think the experience of "dogfooding" our own builds, including our own work-in-progress patches, provides significant "instant feedback" to platform developers - do you expect that we'd all switch to using mobile devices as our primary web-browsing environments? If not, we'd lose much of that hands-on real-life experience. JK |
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mike Shaver |
8/25/11 2:13 PM |
On Thu, Aug 25, 2011 at 4:55 PM, Mark Finkle <mark....@gmail.com> wrote: > We should have all platform development happen first using mobile hardware > (tablets and phones). So all initial coding, profiling and debugging happens > on mobile. Once the code passes the quality and performance levels needed > for mobile, we can then get desktop implementations ready (where separate > desktop impls are actually needed). It's a nice thought experiment, and I've tried to push that rock up the hill a few times, but it always gets stuck on things like: - what profiling? last time I asked about how I profiled on my phone I was told to build a custom ROM, IIRC, and I couldn't do that from anything but a Linux VM. The Android toolchain is much more painful to work with (debugger!) than any of our desktop platforms, and I think that the productivity hit would be very substantial. - unless things have dramatically improved since I last compared, the test coverage is much much lower on mobile than on desktop, and I haven't seen the mobile-expert resources pointed at solving that in an effective way so far. - try server + android = oof We're already hurting from developer ergonomic issues around turn-around time. I just don't think that Firefox on Android is ready to be the primary developer target, though it would be great if it were. I agree that we shouldn't have an isolated mobile group chasing desktop platform or browser improvements; a theme of mine for a couple of years, in fact, and I'm very glad that Damon has been able to make progress on it where I couldn't. But I think that the way to make progress on that now is to spread the mobile knowledge through the existing platform and application teams, and project their expertise into discussions about gfx/networking/whatever. Something I don't understand: what are you seeing happen these days that doesn't meet the mobile performance targets? How do you determine it's the case (Talos?), and why does it differ meaningfully? Other than a very small number of things that are processor-specific, are there patterns around cache or I/O that are problematic, which we could address as an easier step? Mike
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mike Shaver |
8/25/11 2:15 PM |
On Thu, Aug 25, 2011 at 5:11 PM, Jonathan Kew <jfkt...@googlemail.com> wrote: > Also, I think the experience of "dogfooding" our own builds, including our own work-in-progress patches, provides significant "instant feedback" to platform developers - do you expect that we'd all switch to using mobile devices as our primary web-browsing environments? If not, we'd lose much of that hands-on real-life experience. Yeah, I don't think we're there yet. There are a bunch of (known, being-worked-on) things around text editing and zooming, for example, which makes working with bugzilla pretty unproductive. I've tried, but I can't live in my phone for the stuff I do (zimbra, twitter-web, gmail-web, facebook-web, etc.), at least yet. Mike
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mark Finkle |
8/25/11 2:30 PM |
On 08/25/2011 05:11 PM, Jonathan Kew wrote: > On 25 Aug 2011, at 21:55, Mark Finkle wrote: > >> I'd like to propose that Mozilla changes the way we develop the platform. Instead of developing platform changes first on desktop and then trickling down to mobile, we should reverse that. >> >> We should have all platform development happen first using mobile hardware (tablets and phones). So all initial coding, profiling and debugging happens on mobile. Once the code passes the quality and performance levels needed for mobile, we can then get desktop implementations ready (where separate desktop impls are actually needed). > > Interesting approach! > > Offhand, I do have a couple reservations, though... Are the mobile development tools (coding and debugging environments, profiling tools, etc) really up to the level where we could do this without seriously impacting developer productivity? debugging is getting better, but only got better when platform devs focused on making it better. Profiling is the same way. Work is being done related to B2G for profiling and I think this could be moved faster with the extra focus and support fo dozens of devs. > Also, I think the experience of "dogfooding" our own builds, including our own work-in-progress patches, provides significant "instant feedback" to platform developers - do you expect that we'd all switch to using mobile devices as our primary web-browsing environments? If not, we'd lose much of that hands-on real-life experience. This is certainly true, but we need to start the process somewhere. Trying to do any amount of "living" on your tablet would be a great improvement to our current dogfooding and would find a lot of low hanging fruit.
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mike Shaver |
8/25/11 2:37 PM |
On Thu, Aug 25, 2011 at 5:30 PM, Mark Finkle <mark....@gmail.com> wrote: > debugging is getting better, but only got better when platform devs focused > on making it better. Profiling is the same way. what platform work was needed here? I thought it was all toolchain-side stuff that was hurting. (that's certainly where I got stumped a bunch of times.) Mike
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mark Finkle |
8/25/11 2:38 PM |
On 08/25/2011 05:13 PM, Mike Shaver wrote: > On Thu, Aug 25, 2011 at 4:55 PM, Mark Finkle<mark....@gmail.com> wrote: >> We should have all platform development happen first using mobile hardware >> (tablets and phones). So all initial coding, profiling and debugging happens >> on mobile. Once the code passes the quality and performance levels needed >> for mobile, we can then get desktop implementations ready (where separate >> desktop impls are actually needed). > > It's a nice thought experiment, and I've tried to push that rock up > the hill a few times, but it always gets stuck on things like: > > - what profiling? last time I asked about how I profiled on my phone I > was told to build a custom ROM, IIRC, and I couldn't do that from > anything but a Linux VM. The Android toolchain is much more painful > to work with (debugger!) than any of our desktop platforms, and I > think that the productivity hit would be very substantial. Very true, but debugging seems to be improving a lot. Jim Chen build a custom GDB that is state of the art. Profiling is also moving along and if we can't find ways to profile using oprofile, we'll need to find or invent other ways. I have seen Mozilla do amazing things. Lack of an existing profiler will not stop the people I work with. > - unless things have dramatically improved since I last compared, the > test coverage is much much lower on mobile than on desktop, and I > haven't seen the mobile-expert resources pointed at solving that in an > effective way so far. > > - try server + android = oof
This is getting better too. Everyday we find issues with the tegras (dammit) and find ways to fix them too. We are looking to bring panda boards online as well, so we can mix up the hardware a bit. Maybe finding a better hardware platform to use, since the tegras are not even supported by nVidia anymore. We can even run many of our tests from a local machine using ADB and your own phone or tablet! Amazing I know. > Something I don't understand: what are you seeing happen these days > that doesn't meet the mobile performance targets? How do you > determine it's the case (Talos?), and why does it differ meaningfully? > Other than a very small number of things that are processor-specific, > are there patterns around cache or I/O that are problematic, which we > could address as an easier step?
Talos is a good general tool to look for regressions, but I have seen Mozilla devs fallback to simple timing helpers in the code, dumping to stdout as well. And we are not in a regression-watching situation as much as a make-it-faster situation. Things like rendering alpha blurs on ARM are too slow. Forcing reflows when an element is moving in a stack is not cool. I pick these examples cause I know we have bugs filed and patches waiting to improve them. You once told me the Mozilla/Firefox 1.0 improved performance 1% at a time, by any means necessary :)
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mike Shaver |
8/25/11 2:44 PM |
On Thu, Aug 25, 2011 at 5:38 PM, Mark Finkle <mark....@gmail.com> wrote: > You once told me the Mozilla/Firefox 1.0 improved performance 1% at a time, > by any means necessary :) I gotta keep my mouth shut. So I agree that we (everyone, even non-engineers) need to get to the point that making Android your primary development environment is as credible a choice as Linux on a laptop. Once we're there, maybe we can look at making it mandatory, but I have some skepticism about how well that'll actually work. Mike
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mark Finkle |
8/25/11 2:45 PM |
I see our platform devs do amazing things, like Jim Chen taking GDB and getting it bleeding edge for Android, For profiling, I am thinking about tools like Patrick Walton's Piranha: https://github.com/pcwalton/piranha Let's get some devs to make it a first class android profiler. No rooting or ROM's needed.
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mike Hommey |
8/25/11 3:17 PM |
Note that some devices don't even allow to use "runas". Mike
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Robert O'Callahan |
8/25/11 3:27 PM |
On Fri, Aug 26, 2011 at 8:55 AM, Mark Finkle <mark....@gmail.com> wrote: > That might help with situations where features land and work well on > desktop, but don't really meet expectations on mobile. Currently, we would > file a bug to get the platform devs to try to improve the situation on > mobile. Most of the time, the platform devs _do_ try get fixes for mobile, > but sometimes we don't get a fix landed in a timely manner, if at all. > > There are improve-for-mobile bugs currently waiting for dev resources. > > I propose the Mobile First idea for the entire platform development team > and not just create smaller subset teams to focus on mobile. > We did it for multi-process and for layer remoting and I think that was a great success. I think we should do it for more things, but not everything. Examples: Mats Palmgren recently implemented CSS text-overflow. Daniel Holbert is implementing CSS flexbox. Would it make sense to do those on mobile first? I don't think so. There's no reason to believe they'll behave differently on mobile. Ergonomics favour developing them on desktop. More examples: Chris Pearce reduced the thread usage of paused media elements, Mats Palmgren refactored the way we iterate through the various child lists of a frame. Those are sheer performance/maintainability wins on all platforms. I don't see that there would have been any benefit developing them on mobile first. Again, ergonomics favour developing them on desktop. I can see that if we're making changes that have platform-specific effects, or involve performance tradeoffs, doing mobile first or at least concurrently makes sense. (Being serious about not taking regressions means we often have to do mobile and desktop together.) Two areas when we can apply this right now: we should bump the priority of working out the fullscreen API on mobile, and Emerald (GL backend for Azure) should be mobile-focused. Rob -- "If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us." [1 John 1:8-10]
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Patrick Walton |
8/25/11 3:44 PM |
On 8/23/11 7:54 AM, Benjamin Smedberg wrote: >> I get lots of checkerboarding if I pan quickly, moreso than in other >> mobile browsers. Zooming is OK for me, but I do see complaints about it >> in the app store, and the graphics quality during zooming is lower than >> stock, so maybe we are using that to compensate for lower underlying >> performance. > There are tradeoffs that could be made here, but this surprises me > greatly. I generally feel that Firefox is just so stupendously better at > panning/zooming than stock... In general I think stock feels much faster as well. > For example, we allow you to pan and zoom as fast as the chrome will > allow you to do it (which is damn-fast): we asynchronously get updates > for the new regions or zoomed pixels. We *could* intentionally slow down > scrolling so that you can't scroll as fast (so that painting is more > visible), but in general that sounds like the wrong tradeoff. I think if we're framing the question in terms of "which is worse, checkerboards or slow scrolling", we've already lost. Both solutions are really equally bad. IMHO we should shoot for daily browsing at 60 fps with no checkerboards at all, and focus on what is preventing us from reaching that. Patrick
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mark Finkle |
8/25/11 3:53 PM |
On 08/25/2011 06:27 PM, Robert O'Callahan wrote: > On Fri, Aug 26, 2011 at 8:55 AM, Mark Finkle<mark....@gmail.com> wrote: >> I propose the Mobile First idea for the entire platform development team >> and not just create smaller subset teams to focus on mobile. >> > > We did it for multi-process and for layer remoting and I think that was a > great success. I think we should do it for more things, but not everything. Not great success. It took a hell of a long time to get parity with desktop feature on e10s/mobile. We still don't have 100% parity. > Examples: Mats Palmgren recently implemented CSS text-overflow. Daniel > Holbert is implementing CSS flexbox. Would it make sense to do those on > mobile first? I don't think so. There's no reason to believe they'll behave > differently on mobile. Ergonomics favour developing them on desktop. Agreed. But I wonder if profiling on mobile would have show them hot-spots in the code that don't exist for desktop? > More examples: Chris Pearce reduced the thread usage of paused media > elements, Mats Palmgren refactored the way we iterate through the various > child lists of a frame. Those are sheer performance/maintainability wins on > all platforms. I don't see that there would have been any benefit developing > them on mobile first. Again, ergonomics favour developing them on desktop. We have had feedback that video is not acceptable in Fennec on Android. My main point here is that these things are "easier" or "less constrained" on desktop. Does the video team think the video on Fennec is acceptable? I know Derf and others have been working hard to make improvements. > I can see that if we're making changes that have platform-specific effects, > or involve performance tradeoffs, doing mobile first or at least > concurrently makes sense. (Being serious about not taking regressions means > we often have to do mobile and desktop together.) Totally agree. I am being a bit over the top here only because if I'm not, no one really takes it seriously. The status quo hasn't been giving Mozilla the payoffs we want on mobile. > Two areas when we can apply this right now: we should bump the priority of > working out the fullscreen API on mobile, and Emerald (GL backend for Azure) > should be mobile-focused. Yes, those are great candidates.
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Robert O'Callahan |
8/25/11 10:53 PM |
On Fri, Aug 26, 2011 at 10:53 AM, Mark Finkle <mark....@gmail.com> wrote: > On 08/25/2011 06:27 PM, Robert O'Callahan wrote: >
>> Examples: Mats Palmgren recently implemented CSS text-overflow. Daniel >> Holbert is implementing CSS flexbox. Would it make sense to do those on >> mobile first? I don't think so. There's no reason to believe they'll >> behave >> differently on mobile. Ergonomics favour developing them on desktop. >> > > Agreed. But I wonder if profiling on mobile would have show them hot-spots > in the code that don't exist for desktop? I doubt it. Anyway, we haven't really done performance work on either of those features yet; premature optimization being evil and all that.
> More examples: Chris Pearce reduced the thread usage of paused media >> elements, Mats Palmgren refactored the way we iterate through the various >> child lists of a frame. Those are sheer performance/maintainability wins >> on >> all platforms. I don't see that there would have been any benefit >> developing >> them on mobile first. Again, ergonomics favour developing them on desktop. >> > > We have had feedback that video is not acceptable in Fennec on Android. My > main point here is that these things are "easier" or "less constrained" on > desktop. Does the video team think the video on Fennec is acceptable? I know > Derf and others have been working hard to make improvements.
I don't think video is acceptable on Android. If we were implementing video today, it would be a great candidate for "mobile first", but we implemented it years ago.
Rob -- "If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us." [1 John 1:8-10]
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mike Hommey |
8/25/11 11:11 PM |
On Thu, Aug 25, 2011 at 04:06:07PM -0700, Patrick Walton wrote: > On 8/25/11 3:17 PM, Mike Hommey wrote: > >Note that some devices don't even allow to use "runas". >
> Can we build it as something launchable from Firefox itself then, > via nsIProcess or something? Seems that this problem is solvable. I doubt it, it requires privileges to switch user id. runas is effectively a su that can't switch to root but can switch to all other applications users. Mike
|
Firefox Android: Improving Performance |
Thomas Arend |
8/26/11 12:19 PM |
User complaints about slow Performance and high Memory usage are bubbling up in our statistics, making them top issues reported via email, Input, Sumo, Twitter, etc. The other ones are Flash and "I want this on my device". The latter is a "good" problem to have (except for the fact that there are many ARMv6 devices out there). Flash is being mentioned often, but most users still give us a 3, 4 or even 5 star rating - so, albeit important, I wouldn't consider it the most serious deal-breaker. Performance, Memory and CPU usage *are* deal-breakers: (1) Startup Time - actual startup time: seems to vary - based on my own experience it is rarely under 5s, typically 5-10s. Anything slower than the stock browser startup is not acceptable. And, perhaps, we should be even faster: - perceived startup time: instead of showing the "loading..." screen, could we quickly show a cached image of the previous session while loading browser libraries and chrome in the background? This may also help us with WebApps going forward to give an instant native-app-like response to users after tapping the icon. - The startup time issue is all the more severe as Android kills Firefox (and other apps) while running in the background very aggressively (see (2) below). Use Firefox, switch to your Calendar for a minute or play a round of Angry Birds, and go "back" to your browser, and you will see a cold start of our browser. (2) Memory Usage - do we know by how much we can reduce actual memory usage and how exactly that will impact the user experience? - can we avoid getting killed in the background by Android any other way? e.g. by offering a browser widget which could basically be an awesome bar-like search box which could keep some of our libraries in memory? (3) Page switching / rendering - Tap on a link on a page, we start showing the next page as soon as we get the first bytes from the CSS or page - on slower connections you see either checkerboard or white for a while until the page gets loaded. That is a very "honest" way of showing that target page, because we show what we get, as soon as we get it. However, it makes us appear slow! - Most mobile browsers *seem* to switch to the next page only once the page is rendered. Overall, we may be faster, but other browsers seem much faster, as they switch over to the full page while Firefox users can sometimes watch the page to get rendered. *If* this observation is true, could we consider switching to the next page once there to be seen? (4) panning / zooming / readability: - We still checkerboard a lot while loading pages or zooming: e.g. zoom in to NYT.com - zoom out again - see checkerboard while you zoom - panning is not as smooth as in the stock browser - our panning can be laggy, jerky at times: pan up and down quickly to see how the web page follows your movement with a visible delay and "jumps" - try the same with the stock browser - the readability project should take care of the performance issues related to double-tap-to-zoom and reflow, I assume? (5) JS and page load - For JavaScript performance: Kraken makes us look really good, SunSpider shows us just barely faster than the Android stock browser on Honeycomb, and V8 actually shows that we are slower. What would be a measurable goal for us? Can we boost mobile JS performance significantly? And what would be the user impact and visual advantage on your average web page? - Page load: QA did some tests to measure page load times of Fx4 compared to other browsers: the results were mixed, there was no clear winner: we were faster than other browsers on a few pages, but on most pages, stock or other mobile browsers were as fast or faster, in some cases significantly faster. We may run those numbers again under controlled conditions (6) Add-ons and Input Methods - I wonder how add-ons and Swiftkey, Swype, etc. hurt our performance? (7) Measuring and Optimizing Performance - Is the data we get from users today enough to find Performance issues? Or do we need more than beta tools and zippity? - Can we publish concrete guidance for users on how to make their mobile Firefox experience faster? To revolutionize the (mobile) web, we need to set new standards for fastest performance and best ease-of-use to stand out from the crowd and to lead innovation. What matters most to mobile users is a seamless and pleasant online experience across their devices. Being perceived as too slow significantly limits our reach today. We need all your ideas and support to get this fixed as soon as possible. Thanks for sharing your ideas. On Aug 24, 10:13 am, Michael Verdi <mve...@mozilla.com> wrote: > Mike Hommey wrote: > > There is absolutely no way we can get as fast as the "native" browser > > We've got a big problem then. Even the people who love Firefox complain > that it's too slow.https://market.android.com/details?id=org.mozilla.firefoxhttps://input.mozilla.com/en-US/?q=slow&product=mobile&version=--&sen... > > - Michael
|
Re: Firefox Android: Improving Performance |
Mike Shaver |
8/26/11 12:39 PM |
On Fri, Aug 26, 2011 at 3:19 PM, Thomas Arend <tarend...@gmail.com> wrote: > - do we know by how much we can reduce actual memory usage and how > exactly that will impact the user experience? I think that using ashmem for discardable memory (JIT code, maybe; image cache; off-screen tabs if we don't already discard; thumbnails; memory cache) would let us reduce our effective memory footprint under pressure a fair bit. I think dougt is looking into this, and I'm pretty sure it's what the Android browser and other system apps do. > - can we avoid getting killed in the background by Android any other > way? e.g. by offering a browser widget which could basically be an > awesome bar-like search box which could keep some of our libraries in > memory? I think that'd be more likely to get both of them killed, but it also seems sort of user-hostile. Maybe I'm over-reacting, though. Mike
|
Re: Firefox Android: Improving Performance |
Mark Finkle |
8/26/11 12:52 PM |
On 08/26/2011 03:19 PM, Thomas Arend wrote: > (1) Startup Time > - actual startup time: seems to vary - based on my own experience it > is rarely under 5s, typically 5-10s. Anything slower than the stock > browser startup is not acceptable. And, perhaps, we should be even > faster: > - perceived startup time: instead of showing the "loading..." screen, > could we quickly show a cached image of the previous session while > loading browser libraries and chrome in the background? This may also > help us with WebApps going forward to give an instant native-app-like > response to users after tapping the icon. Some current bugs for improving startup: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=sw%3Amobilestartupshrink > - The startup time issue is all the more severe as Android kills > Firefox (and other apps) while running in the background very > aggressively (see (2) below). Use Firefox, switch to your Calendar for > a minute or play a round of Angry Birds, and go "back" to your > browser, and you will see a cold start of our browser. This is more memory related, and less startup > (2) Memory Usage > - do we know by how much we can reduce actual memory usage and how > exactly that will impact the user experience? > - can we avoid getting killed in the background by Android any other > way? e.g. by offering a browser widget which could basically be an > awesome bar-like search box which could keep some of our libraries in > memory? Killing the child process is another drastic way to reduce the memory footprint > (4) panning / zooming / readability: > - We still checkerboard a lot while loading pages or zooming: e.g. > zoom in to NYT.com - zoom out again - see checkerboard while you zoom > - panning is not as smooth as in the stock browser - our panning can > be laggy, jerky at times: pan up and down quickly to see how the web > page follows your movement with a visible delay and "jumps" - try the > same with the stock browser > - the readability project should take care of the performance issues > related to double-tap-to-zoom and reflow, I assume? You are referring to: https://bugzilla.mozilla.org/show_bug.cgi?id=627842 I don't know if this affects reflow-on-zoom behavior. It is more about pure readability. > - Page load: QA did some tests to measure page load times of Fx4 > compared to other browsers: the results were mixed, there was no clear > winner: we were faster than other browsers on a few pages, but on most > pages, stock or other mobile browsers were as fast or faster, in some > cases significantly faster. We may run those numbers again under > controlled conditions > (6) Add-ons and Input Methods > - I wonder how add-ons and Swiftkey, Swype, etc. hurt our performance? * Regarding add-ons, what's true for desktop is true for mobile: add-ons _can_ slow down the app. * Keyboards/IMEs have been a pain on mobile, but I don't think performance is the main issue. I could be wrong. > (7) Measuring and Optimizing Performance > - Is the data we get from users today enough to find Performance > issues? Or do we need more than beta tools and zippity? > - Can we publish concrete guidance for users on how to make their > mobile Firefox experience faster? We need better tools for measuring code speed. Talos, Telemetry and Zippity are good for a certain class of data, but we need more fine-grained tools as well. Some possible examples include: * https://wiki.mozilla.org/Using_SlowCalls * https://github.com/pcwalton/piranha There is a bug filed to create nightly builds that are "slow-call" enabled, which would make it easier for people to get some JS profile data: https://bugzilla.mozilla.org/show_bug.cgi?id=592518
|
Re: Firefox Android: Improving Performance |
Mark Finkle |
8/26/11 12:55 PM |
On 08/26/2011 03:52 PM, Mark Finkle wrote: > On 08/26/2011 03:19 PM, Thomas Arend wrote: > >> (1) Startup Time >> - actual startup time: seems to vary - based on my own experience it >> is rarely under 5s, typically 5-10s. Anything slower than the stock >> browser startup is not acceptable. And, perhaps, we should be even >> faster: >> - perceived startup time: instead of showing the "loading..." screen, >> could we quickly show a cached image of the previous session while >> loading browser libraries and chrome in the background? This may also >> help us with WebApps going forward to give an instant native-app-like >> response to users after tapping the icon. > > Some current bugs for improving startup: > https://bugzilla.mozilla.org/buglist.cgi?quicksearch=sw%3Amobilestartupshrink See also: * Bug 663762 - Splash screen could offer more information to the user (caching the last screenshot) * Bug 675051 - Load minimal amount of UI at startup
|
Re: Firefox Android: Improving Performance |
Michael Verdi |
8/26/11 4:00 PM |
Thomas Arend wrote: > Performance, Memory and CPU usage *are* deal-breakers: > (1) Startup Time
> (2) Memory Usage > I agree with this 100%. Mark Finkle wrote: > See also: > > * Bug 663762 - Splash screen could offer more information to the user > (caching the last screenshot) > * Bug 675051 - Load minimal amount of UI at startup
I hope we can do something. The current situation makes me groan when I see the Firefox logo. That makes me sad. - Michael
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Doug Turner |
8/29/11 2:22 PM |
> Ergonomics favour developing them on desktop. Hey Roc, I think this is correct. If you can design and develop and debug on the desktop, that is great. What I don't want to see is mobile as an afterthought. The people you mentioned should be testing along the way to ensure that what they are building will work great on mobile. Doug |
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Taras Glek |
8/31/11 2:51 PM |
On 08/23/2011 08:21 PM, Joe Drew wrote: > > On 2011-08-23 1:35 AM, Mike Hommey wrote: >> We should aim at having the UI show up under 1.5s, > > I would go even further: set a goal of having Fennec up and running, and > responsive to interaction, in 1s. > > This is what folks working on making Linux boot fast did[1]. If you say > "We should boot faster", you look at making 10% improvements. If you say > "We should boot fast", you look at the problem in a totally different way. It's easy to set that goal for a kernel. It only has itself to blame for startup speed. We actually have to fight kernel, linker, android userspace, etc. A lot less room for aggressive improvements. We can't realistically aim for < 1.5s given the environment we are running it. For comparison, on maemo we couldn't aim < 3s. Taras
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Taras Glek |
8/31/11 3:11 PM |
Actually telemetry reports amount of ram and number of cpu cores. We do not yet report cpuid Taras |
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Taras Glek |
8/31/11 3:11 PM |
On 08/25/2011 01:10 PM, Mark Finkle wrote:
Actually telemetry reports amount of ram and number of cpu cores. We do
not yet report cpuidTaras |
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Taras Glek |
8/31/11 3:29 PM |
I think low-level platform performance work is easier to measure on mobile the cost of memcpy, context-switches, IO, etc is higher. I suspect the same might apply to optimizing how/when we repaint stuff. I suspect JS people might find some perf tradeoff decisions easier to make due to perf differences being bigger on mobile. Stuff likes deciding on when to discard memory should be a lot more obvious on mobile. The recent big wins in performance-team department all came out of "does it help mobile" mindset: omnijar, startupcache, elfhack, fat libxul.so, etc. The next set of GCC(PGO-guided ordering, etc) improvements are also being targeted at mobile too. Taras
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Robert Kaiser |
9/1/11 6:02 AM |
Taras Glek schrieb: > For comparison, on maemo we couldn't aim < 3s.
To be fair, the reason for that was not maemo itself but the hardware of the N900 with a 600MHz CPU and 256MB of RAM. I'm pretty sure on an Android phone with those constraints, <3s would also be unrealistic - if we run at all. Robert Kaiser -- Note that any statements of mine - no matter how passionate - are never meant to be offensive but very often as food for thought or possible arguments that we as a community should think about. And most of the time, I even appreciate irony and fun! :)
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Joe Drew |
9/1/11 1:14 PM |
On 2011-08-31 5:51 PM, Taras Glek wrote: > It's easy to set that goal for a kernel. It only has itself to blame for > startup speed. We actually have to fight kernel, linker, android > userspace, etc. A lot less room for aggressive improvements. We can't > realistically aim for < 1.5s given the environment we are running it.
The goal was not just for the kernel; it was to boot to desktop, with all I/O done, disk idle, computer ready to go. They made kernel changes as part of that project, but that was only part of the story. I urge you to read the LWN story[1] if you haven't; it's very enlightening and has changed my outlook on how to make systems fast. Joe 1. https://lwn.net/Articles/299483/
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Mike Hommey |
9/1/11 3:57 PM |
On Thu, Sep 01, 2011 at 04:14:59PM -0400, Joe Drew wrote: > > On 2011-08-31 5:51 PM, Taras Glek wrote: > >It's easy to set that goal for a kernel. It only has itself to blame for > >startup speed. We actually have to fight kernel, linker, android > >userspace, etc. A lot less room for aggressive improvements. We can't > >realistically aim for < 1.5s given the environment we are running it. > > The goal was not just for the kernel; it was to boot to desktop, > with all I/O done, disk idle, computer ready to go. They made kernel > changes as part of that project, but that was only part of the > story. The point is: unless you change the kernel, the linker and android userspace, you can't set incredible goals. That's hard to do on consumer phones. Mike
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Henri Sivonen |
9/4/11 4:06 AM |
On Thu, Aug 25, 2011 at 6:07 PM, Asa Dotzler < a...@mozilla.com> wrote: > David Tenser wrote: >> >> Really good video that summarizes two of the main issues I see with >> Fennec today. Although speed improvements are critical and will to some >> extent get better as hardware becomes faster, a far more Fennec-specific >> issue is the way zooming is handled. As can be seen on this video, you >> can't actually read the text on a stock Fennec install. > > I don't use smartphones so I can't comment much about the readability issues > there but I don't find the zoom thing to be any barrier to using Fennec on > tablet with decent resolution. What size is your tablet? I think the failure to rewrap text blocks to screen width when zooming is *the* major problem in Firefox for Android (on fast phones like Galaxy S II it is worse that any perf issue). See the true story in https://bugzilla.mozilla.org/show_bug.cgi?id=684570 . However, the same friend for whom (apparent) lack of rewrap on zoom was a deal-breaker on Galaxy S II is OK with not having the feature on a 10" Android tablet. I haven't tried a 10" Android tablet, but for me it was a deal-breaker still on a 7" tablet when I considered buying the original Galaxy Tab last year. -- Henri Sivonen hsiv...@iki.fi http://hsivonen.iki.fi/
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
L. David Baron |
9/4/11 7:39 AM |
On Sunday 2011-09-04 14:06 +0300, Henri Sivonen wrote: > What size is your tablet? I think the failure to rewrap text blocks to > screen width when zooming is *the* major problem in Firefox for > Android (on fast phones like Galaxy S II it is worse that any perf > issue). See the true story in > https://bugzilla.mozilla.org/show_bug.cgi?id=684570 . However, the > same friend for whom (apparent) lack of rewrap on zoom was a > deal-breaker on Galaxy S II is OK with not having the feature on a 10" > Android tablet. I haven't tried a 10" Android tablet, but for me it > was a deal-breaker still on a 7" tablet when I considered buying the > original Galaxy Tab last year. I think it's even better to have font sizes inflated to begin with, so that there doesn't need to be reflow on zoom (with the weird modality that introduces, and the weird distinction between zooming with multitouch and the less-discoverable zooming with double-tap). I'm working on that in https://bugzilla.mozilla.org/show_bug.cgi?id=627842 -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla Corporation http://www.mozilla.com/ 𝄂
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Henri Sivonen |
9/4/11 10:05 AM |
On Sun, Sep 4, 2011 at 5:39 PM, L. David Baron <dba...@dbaron.org> wrote: > I think it's even better to have font sizes inflated to begin with, > so that there doesn't need to be reflow on zoom This risks breaking desktop-oriented layouts while the HTC/Opera solution doesn't. > (with the weird modality that introduces, What weird modality do you mean? In the HTC flavor of the stock browser and in Opera Mobile, the rewrapping works great. What's weird about it? Do you mean weird from the user point of view or weird from the CSS point of view? > and the weird distinction between zooming > with multitouch and the less-discoverable zooming with double-tap). I think having a distinction is a bug in Fennec. AFAICT, there's no distinction between double-tap and pinch zooming as far as how rewrapping behaves at a given zoom level in the HTC flavor of the stock browser or in Opera Mobile, which is, IMO, how it should be. > I'm working on that in > https://bugzilla.mozilla.org/show_bug.cgi?id=627842 Is there a reason why this this solution would be better than the HTC/Opera solution (other than not having to reflow inline content when zooming)? Are there any plans to implement the behavior that Opera Mobile has? (At any zoom level, no matter how the user arrives at the zoom level, the inline content in a block wraps as if the inner width of the block didn't exceed the width of the screen but the outer dimensions of the block--including the border dimensions--don't change.) -- Henri Sivonen hsiv...@iki.fi http://hsivonen.iki.fi/
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
L. David Baron |
9/4/11 10:17 AM |
On Sunday 2011-09-04 20:05 +0300, Henri Sivonen wrote: > On Sun, Sep 4, 2011 at 5:39 PM, L. David Baron <dba...@dbaron.org> wrote: > > I think it's even better to have font sizes inflated to begin with, > > so that there doesn't need to be reflow on zoom > > This risks breaking desktop-oriented layouts while the HTC/Opera > solution doesn't. It seems to work pretty well on iOS. > > (with the weird modality that introduces, > > What weird modality do you mean? In the HTC flavor of the stock > browser and in Opera Mobile, the rewrapping works great. What's weird > about it? Do you mean weird from the user point of view or weird from > the CSS point of view? I mean from a user point of view: that there's one set of zooming commands (double-tap) that cause rewrapping and one set (multitouch) that don't. This is particularly weird for users who do predominantly multitouch, and need to learn (1) that if they want to zoom on text they need to not use multitouch and (2) once they do that, they also can't zoom back out using multitouch. > > and the weird distinction between zooming > > with multitouch and the less-discoverable zooming with double-tap). > > I think having a distinction is a bug in Fennec. AFAICT, there's no It's the same in the stock Android browser. > distinction between double-tap and pinch zooming as far as how > rewrapping behaves at a given zoom level in the HTC flavor of the > stock browser or in Opera Mobile, which is, IMO, how it should be. I'd be interested to experiment with such a UI; I've never had a chance to. It's really not clear to me what panning should do once you're zoomed like that. Does the panning UI ignore the rewrapping behavior entirely (and always position the content at the start-edge), or does it do something more clever? Either way, I think it breaks the simple mental model of multitouch zoom + pan. > Is there a reason why this this solution would be better than the > HTC/Opera solution (other than not having to reflow inline content > when zooming)? I think it's a much simpler mental model for users; it doesn't break the multitouch zoom+pan model at all. -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla Corporation http://www.mozilla.com/ 𝄂
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Henri Sivonen |
9/4/11 10:44 AM |
On Sun, Sep 4, 2011 at 8:17 PM, L. David Baron <dba...@dbaron.org> wrote: > On Sunday 2011-09-04 20:05 +0300, Henri Sivonen wrote: >> On Sun, Sep 4, 2011 at 5:39 PM, L. David Baron <dba...@dbaron.org> wrote: >> > I think it's even better to have font sizes inflated to begin with, >> > so that there doesn't need to be reflow on zoom >> >> This risks breaking desktop-oriented layouts while the HTC/Opera >> solution doesn't. > > It seems to work pretty well on iOS. I disagree. I think what Opera Mobile does is vastly superior to what Mobile Safari does. (I'm actually rather surprised that users who haven't tried anything better consider Mobile Safari good enough on this front.) >> > (with the weird modality that introduces, >> >> What weird modality do you mean? In the HTC flavor of the stock >> browser and in Opera Mobile, the rewrapping works great. What's weird >> about it? Do you mean weird from the user point of view or weird from >> the CSS point of view? > > I mean from a user point of view: that there's one set of zooming > commands (double-tap) that cause rewrapping and one set (multitouch) > that don't. This is particularly weird for users who do > predominantly multitouch, and need to learn (1) that if they want to > zoom on text they need to not use multitouch and (2) once they do > that, they also can't zoom back out using multitouch. A distinction between the zooming gestures isn't an inherent characteristic of rewrapping on zoom. Opera Mobile doesn't have such a distinction. >> > and the weird distinction between zooming >> > with multitouch and the less-discoverable zooming with double-tap). >> >> I think having a distinction is a bug in Fennec. AFAICT, there's no > > It's the same in the stock Android browser. OK. It's been a while since I've experimented with this in the HTC flavor of the stock browser. >> distinction between double-tap and pinch zooming as far as how >> rewrapping behaves at a given zoom level in the HTC flavor of the >> stock browser or in Opera Mobile, which is, IMO, how it should be. > > I'd be interested to experiment with such a UI; I've never had a > chance to. It's really not clear to me what panning should do once > you're zoomed like that. Does the panning UI ignore the rewrapping > behavior entirely (and always position the content at the > start-edge), or does it do something more clever? Either way, I > think it breaks the simple mental model of multitouch zoom + pan. In Opera Mobile, panning doesn't affect wrapping. So if you've zoomed so much that the width of the screen is narrower than the width (as in between paddings) of the block, the lines in the block wrap so that the text occupies the left side of the block box (at least for LTR text) and the right side of the block box just shows the background. So if you pan to see stuff on the right, you first have to pan over the empty space in the block box, since rewrapping doesn't change the width of any block box. Since the wrapping happens on a per block-box basis in Opera, when you encounter a block box whose right edge of the left padding is not aligned with the right edge of the left padding of the box above it, you may have to pan sideways a little. For example, if you have a list item or a blockquote, the width at which text wraps in the list items or blockquotes is the same as in paragraphs, but the text in list items and blockquotes starts more to the right, so you have to pan a bit to recenter on the list item or blockquote. (Aside: When the same situation occurs in non-touch Opera Mini, Opera Mini helpfully does the recentering on behalf of the users.) So the effect on panning isn't ideal, but I think the effect on zooming is *vastly* superior to whatever Mobile Safari does or what Firefox does by default or what the Samsung flavor of the Android browser does. >> Is there a reason why this this solution would be better than the >> HTC/Opera solution (other than not having to reflow inline content >> when zooming)? > > I think it's a much simpler mental model for users; it doesn't break > the multitouch zoom+pan model at all. If the text size that the solution chooses is still too small when the line length matches the screen width, what recourse does the user have? With Opera Mobile, the user can choose any zoom level and the line length adjusts so that any given block can be read without horizontal panning. -- Henri Sivonen hsiv...@iki.fi http://hsivonen.iki.fi/
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
L. David Baron |
9/4/11 11:07 AM |
On Sunday 2011-09-04 20:44 +0300, Henri Sivonen wrote: > If the text size that the solution chooses is still too small when the > line length matches the screen width, what recourse does the user > have? With Opera Mobile, the user can choose any zoom level and the > line length adjusts so that any given block can be read without > horizontal panning. Yeah, I agree that that's a problem; it's hard to offer a solution in the font size inflation model other than a preference for the "minimum readable text size". I think combining the zoom-method-independent rewrapping that you describe with font size inflation may be a best-of-both-worlds solution. -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla Corporation http://www.mozilla.com/ 𝄂
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Matt Brubeck |
9/4/11 1:14 PM |
On 09/04/2011 10:17 AM, L. David Baron wrote: > On Sunday 2011-09-04 20:05 +0300, Henri Sivonen wrote: >> On Sun, Sep 4, 2011 at 5:39 PM, L. David Baron<dba...@dbaron.org> wrote: >>> I think it's even better to have font sizes inflated to begin with, >>> so that there doesn't need to be reflow on zoom >> >> This risks breaking desktop-oriented layouts while the HTC/Opera >> solution doesn't. > > It seems to work pretty well on iOS. iOS also has a "-webkit-text-size-adjust" that authors can use to prevent text scaling if it breaks their layouts. To prevent broken pages in Fennec, we might need to implement a similar property, *and* we would need authors to actually use it. > I'd be interested to experiment with such a UI; I've never had a > chance to. It's really not clear to me what panning should do once > you're zoomed like that. I agree with Henri that Opera Mobile 11 for Android solves these problems really well, and I prefer it to the iOS Safari approach.
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Nicholas Nethercote |
9/6/11 11:49 PM |
On Tue, Aug 23, 2011 at 11:18 AM, David Mandelin < dman...@mozilla.com> wrote: > (Oops--posted this to mozilla.dev.performance and dev-planning@lists by > mistake--I meant to post in dev.planning both ways. Please add the list > to followups to keep conversation together.) > > I've been thinking a bit about what can do, and what we need to do, for > Firefox performance on mobile devices.
I'm late to the party here. I want to make a suggestion relating to memory usage: to really get mobile memory usage down, we need a clear target. I wrote about memory targets on the MemShrink wiki page (https://wiki.mozilla.org/Performance/MemShrink#areweslimyet.com), and compared the situation to JS performance and arewefastyet.com (a.k.a AWFY): > Why was AWFY so successful? Some key characteristics. > > - The benchmarks were easy to choose: everybody already used SS and V8, and > then Mozilla released Kraken. They run quickly, too, which is nice for > devs, and allows expensive tools (like Cachegrind) to be used. > > - The metrics were easy to choose. SS time, V8 time, Kraken time. They can be > measured easily, precisely, and fairly repeatably. You can break the total > time down into per-benchmark times, which really helps with understanding > improvements and regressions. They're easy for devs to run on their own > machine. > > - Understanding where the time went was fairly easy, because there are good > time-oriented profilers: Shark, Cachegrind, etc. > > - There was a well-defined goal: match or beat the other browsers. > > In comparison, for AWSY there is no good and/or standard benchmark suite; > metrics are less clear and/or harder to measure; the memory profiling tools > aren't as good; but most importantly, there's no well-defined goal w.r.t. any > benchmarks. This is all very cautious. It's time to be bolder. - W.r.t. profilers: about:memory is much better now, which really helps, and it will continue to do so -- we have 16 open bugs for additional memory reporters, and 13 of them are assigned, so we should make great progress in the next few weeks. (But this point relates only minimally to the question of a hard target, so I'll move on.) - W.r.t. metrics: let's just choose RSS. It measures physical memory usage, and you can't get much central than that. Equally importantly, it's reported (via about:memory) from /proc/<pid>/maps which comes from the kernel, so it's as trustworthy as anything. (In comparison, the Android task manager seems to give funny numbers, I think this might be because it measures "Uss" (http://elinux.org/Android_Memory_Usage) which will under-report for us due to our two process architecture.) - W.r.t. benchmarks: let's just pick some important sites. gmail.com, facebook.com. Something popular. - W.r.t. goals: if we can base this on a particular device or devices (e.g. phone X has 512MB of memory, let's target that) then well and good. Failing that, let's just pick something arbitrary, like 2x less memory than what we currently use. In other words, let's just set a goal like "get total RSS for the two processes when opening sites A, B, and C below X MB". Then we can track it like we did with AWFY. You can say "well, maybe that's not the best thing to measure, blah blah" to which I say "yeah, Sunspider and V8 are pretty crappy measures of JS performance but AWFY still helped our general JS performance hugely". Having a fixed target, even a flawed one, gets everyone's attention. You make what you measure. Without a clear target we're less likely to make progress. Nick
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
timeless |
9/7/11 12:41 AM |
Gmail/facebook are problematic because neither their content nor their site design is stable. One could use a snapshot of a wikipedia article, or perhaps a fixed version of etherpad (and page content). One could even use a fixed version of zimbra (with fixed content). > _______________________________________________ > dev-planning mailing list > dev-pl...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-planning > -- Sent from my mobile device
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Nicholas Nethercote |
9/7/11 12:54 AM |
On Wed, Sep 7, 2011 at 5:41 PM, timeless <time...@gmail.com> wrote: > Gmail/facebook are problematic because neither their content nor their > site design is stable. > > One could use a snapshot of a wikipedia article, or perhaps a fixed > version of etherpad (and page content). One could even use a fixed > version of zimbra (with fixed content). Sure, and people will probably quibble with my other suggestions. That's fine and good! But the basic idea (pick a reasonable, specific target and push hard towards it) is unchanged. Nick
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
JP Rosevear |
9/8/11 7:44 AM |
On Sun, 2011-09-04 at 11:07 -0700, L. David Baron wrote:
> On Sunday 2011-09-04 20:44 +0300, Henri Sivonen wrote:
> > If the text size that the solution chooses is still too small when the
> > line length matches the screen width, what recourse does the user
> > have? With Opera Mobile, the user can choose any zoom level and the
> > line length adjusts so that any given block can be read without
> > horizontal panning.
>
> Yeah, I agree that that's a problem; it's hard to offer a solution
> in the font size inflation model other than a preference for the
> "minimum readable text size".
>
> I think combining the zoom-method-independent rewrapping that you
> describe with font size inflation may be a best-of-both-worlds
> solution.
What David is working on is also covered in:
https://wiki.mozilla.org/Fennec/Features/readability
As you can see a lot of discussion went on before picking a way forward.
-JP
--
JP Rosevear < j...@mozilla.com>
Mozilla
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Nicholas Nethercote |
9/8/11 7:11 PM |
On Tue, Sep 6, 2011 at 11:49 PM, Nicholas Nethercote <n.neth...@gmail.com> wrote: > > - W.r.t. metrics: let's just choose RSS. It measures physical memory usage, > and you can't get much central than that. Equally importantly, it's > reported (via about:memory) from /proc/<pid>/maps which comes from the > kernel, so it's as trustworthy as anything. I was doing some thinking about this. A typical thing people do is start up the browser, load a page or two, then measure memory usage. Let's call this the "stable" memory usage. They'll often use about:memory or a task manager to do this. Unfortunately, stable usage can be substantially lower than peak usage. I just tried loading Gmail and TechCrunch in a Linux64 desktop dev build; stable RSS was 284MB, but peak RSS was 341MB, which is 1.2x higher. Which is more important? I've heard that on some devices Fennec is killed as soon as it starts paging. If that's true, then peak is certainly important. Unfortunately, peak isn't easy to measure. You can get peak RSS from /proc/<pid>/status on Linux (and Android?), it's the "VmHWM" field. (And current RSS is the "VmRSS" field.) That's how I got my numbers above. And you can get peak vsize similarly ("VmPeak" and "VmSize"). But global numbers like RSS and vsize only get us so far. All the detailed measurements in about:memory are stable measurements, not peak. The only way I know of to get detailed peak measurements is with Massif. Unfortunately, Massif is a pain to use. I know of three things that can cause short-lived memory spikes: - The cycle collector. I've seen this take over 20MB before. - JSParseNode. I've seen this take as much as 70MB before, and https://bugzilla.mozilla.org/show_bug.cgi?id=626932 is open about it. (We made this a MemShrink:P3 bug because the usage is very short-lived but now I wonder if we should reconsider that. Happily, Brendan is looking at it.) - Type inference has some temporary analysis data that is cleared on each GC. It's long-lived enough that it shows up on about:memory under "analysis-temporary". The first two of these I know about because they show up a lot in Massif profiles (e.g. http://blog.mozilla.com/nnethercote/2010/12/09/memory-profiling-firefox-with-massif/). I'm not sure what to do about this right now, but I thought it worth mentioning. The "dark matter" of the "heap-unclassified" entry in about:memory has received a lot of attention because it's obvious. This difference between peak and stable usage is another kind of dark matter that's much less obvious but might be as important. Nick
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Boris Zbarsky |
9/8/11 7:26 PM |
On 9/8/11 10:11 PM, Nicholas Nethercote wrote: > I know of three things that can cause short-lived memory spikes: Some other things that I think can do it: 1) Frame construction (creation of all the frame construction items before we create frames for them). The good news is that most pages have few enough elements that this has a hard time going over a few MB. 2) Painting (display lists). 3) Rulehash construction (has some temporary data structures that are O(N) in size in number of CSS selectors used on the page; again, this is usually not that bad because pages have at most ~20k selectors and the temp data is < 32 bytes per selector, I'm pretty sure). 4) Ruletree growth when dynamic changes are happening before ruletree GC happens. 5) Script and stylesheet parsing: for a bit the source and the parsed representation are both in memory at once. The spike size is the size of the script or stylesheet text, so probably a few hundred KB on pages where there are significant scripts/stylesheets. I suspect these are all much smaller allocations than the ones you mention, though. -Boris
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
Andrew McCreight |
9/9/11 8:11 AM |
----- Original Message -----
> I know of three things that can cause short-lived memory spikes:
>
> - The cycle collector. I've seen this take over 20MB before.
It shouldn't be that hard to calculate the peak memory of the cycle collector. It could be reported in about:memory under "other measurements", or just disabled with the normal build flags. IIRC, about half of this was a hash table. The hash table also takes about 8% of total cycle collection time. It may be worth looking into if we can replace it with a better hash table.
Andrew
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
David Mandelin |
9/9/11 2:17 PM |
On 8/25/2011 10:46 AM, Michelle Luna wrote:
> On 8/24/11 7:20 PM, David Mandelin wrote:
>> On 8/23/2011 10:20 PM, Wesley Johnston wrote:
>>>> I think I agree, but I'm not sure yet. Opera has a feature where if you
>>>> scroll fast, they show a button with an up or down arrow that will
>>>> scroll you all the way, which I thought was just generally neat, but
>>>> they might also have added it to mitigate their slower scrolling.
>>> We actually have a feature in Fennec where two finger up or down swipes
>>> will take you to the top and bottom of documents (left and right move
>>> back
>>> and forward in history),
>> Hey, cool! I've been wanting some feature that did that, and I didn't
>> know we had that. Do our users know? How do we teach them?
For some reason I just saw this.
> One great way to teach users about new features is to create or update
> an article on SUMO. I've added a draft article for using gestures on
> mobile here:
> https://support.mozilla.com/en-US/kb/how-do-i-use-firefox-gestures-my-mobile-device/revision/16681
Works for me.
> Just register and then edit the wiki any time you have a solution you
> want to document or improve.
I'll try to remember that.
> On the larger topic of performance, we also need an article for the
> short-term to help folks sort out why Firefox for Mobile is slow, so I
> started a troubleshooting article for that problem here:
> https://support.mozilla.com/en-US/kb/why-firefox-mobile-slow/revision/16686
Hmmm, that's a tough one. It seems like for many users the real answer
is "wait until we do a bunch of work". I guess the note about Beta and
Aurora points in that direction.
Do you track how helpful the articles are to users?
> Let me know what you think.
>
> Thanks,
> Michelle Luna
> Firefox for Mobile Support
> http://www.meetup.com/Firefox-Android-superheroes/
|
Re: Android/ARM Firefox Perforamance: where we are and where to go |
David Mandelin |
9/9/11 2:35 PM |
I think RSS is a good choice.
> - W.r.t. benchmarks: let's just pick some important sites. gmail.com,
> facebook.com. Something popular.
At this point, it hardly matters what website you choose: most of the
memory seems to be in the main process just for existing. gmail and
facebook have apps, and the mobile web experience for them is bad, so
I'd go with something else. Maybe Google News.
> - W.r.t. goals: if we can base this on a particular device or devices (e.g.
> phone X has 512MB of memory, let's target that) then well and good. Failing
> that, let's just pick something arbitrary, like 2x less memory than what we
> currently use.
>
> In other words, let's just set a goal like "get total RSS for the two processes
> when opening sites A, B, and C below X MB". Then we can track it like we did
> with AWFY. You can say "well, maybe that's not the best thing to measure, blah
> blah" to which I say "yeah, Sunspider and V8 are pretty crappy measures of JS
> performance but AWFY still helped our general JS performance hugely".
>
> Having a fixed target, even a flawed one, gets everyone's attention. You make
> what you measure. Without a clear target we're less likely to make progress.
IMO, the common notion that SunSpider and V8 are bad benchmarks misses
the mark (going after the common notion here, not your quoting of it).
Optimizing for them has in fact driven a lot of great JS performance
work, and that's a bigger contribution than anything else those
benchmarks could have done. So I say they are not actually bad
benchmarks. (Actually, SunSpider seems to be obsolete now, but it's just
a victim of its own success.)
Anyway, I think some care is still warranted in target selection. If we
choose a target that is not aggressive enough, then we may find
ourselves taking half-measures that don't actually get us where we want
to go. E.g., with JM, our target was something like "equal to or the
best on SunSpider, equal or tie Safari on V8, get kind of close to V8 on
V8." The first two were pretty ambitious goals that we did reach. The
third was a realistic goal: we knew V8 was especially good on V8, and
that we would not be able to equal them without generational GC.
If we had chosen a lesser target (get halfway to parity on SunSpider),
we would have done less work and reached that lesser target instead. And
our JS perf would be considered bad. And if we chose something
impossible, like beating V8 on V8, we would have wasted a lot of effort
trying to rush generational GC or something, and failed.
Of course you can always adjust targets as you go, but every day working
toward the wrong target costs.
Anyway, it seems Opera Mobile is the leader in memory usage. We're
probably not ready to aim at that target yet. Parity with stock would be
a good target, though--that'd be my default choice. To make it concrete:
choose 5 popular pages, say within 10% of stock on each of the 5 loaded
individually and all 5 in tabs.
I think we'll have to pursue some really aggressive projects to hit that
target.
Dave
|