Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Android/ARM Firefox Perforamance: where we are and where to go

375 views
Skip to first unread message

David Mandelin

unread,
Aug 22, 2011, 9:18:33 PM8/22/11
to
(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

Matt Brubeck

unread,
Aug 22, 2011, 10:47:07 PM8/22/11
to David Mandelin
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.

Boris Zbarsky

unread,
Aug 22, 2011, 10:50:13 PM8/22/11
to dev-pl...@lists.mozilla.org
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

Boris Zbarsky

unread,
Aug 22, 2011, 10:50:13 PM8/22/11
to dev-pl...@lists.mozilla.org
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,

Jonas Sicking

unread,
Aug 22, 2011, 10:54:36 PM8/22/11
to Matt Brubeck, dev-pl...@lists.mozilla.org

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

Matt Brubeck

unread,
Aug 22, 2011, 11:11:38 PM8/22/11
to David Mandelin
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

Justin Lebar

unread,
Aug 22, 2011, 11:16:15 PM8/22/11
to dev-pl...@lists.mozilla.org
>> 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.

Justin Lebar

unread,
Aug 22, 2011, 11:16:15 PM8/22/11
to mozilla.de...@googlegroups.com, dev-pl...@lists.mozilla.org
>> 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.

Matt Brubeck

unread,
Aug 22, 2011, 11:25:31 PM8/22/11
to
>> 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.

Robert O'Callahan

unread,
Aug 22, 2011, 11:32:01 PM8/22/11
to David Mandelin, dev-pl...@lists.mozilla.org
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]

L. David Baron

unread,
Aug 23, 2011, 12:07:09 AM8/23/11
to Robert O'Callahan, dev-pl...@lists.mozilla.org, David Mandelin
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/ 𝄂

Mike Hommey

unread,
Aug 23, 2011, 1:35:29 AM8/23/11
to David Mandelin, dev-pl...@lists.mozilla.org
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

Axel Hecht

unread,
Aug 23, 2011, 7:13:04 AM8/23/11
to
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

Kyle Huey

unread,
Aug 23, 2011, 7:26:32 AM8/23/11
to David Mandelin, dev-pl...@lists.mozilla.org
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

Ali Juma

unread,
Aug 23, 2011, 9:50:19 AM8/23/11
to Matt Brubeck, dev-pl...@lists.mozilla.org

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

Ludovic Hirlimann

unread,
Aug 23, 2011, 10:11:51 AM8/23/11
to

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

Robert Kaiser

unread,
Aug 23, 2011, 10:26:34 AM8/23/11
to
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! :)

Robert Kaiser

unread,
Aug 23, 2011, 10:30:20 AM8/23/11
to
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.

Benjamin Smedberg

unread,
Aug 23, 2011, 10:54:31 AM8/23/11
to David Mandelin, dev-pl...@lists.mozilla.org, dev-per...@lists.mozilla.org
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

Mark Finkle

unread,
Aug 23, 2011, 10:56:01 AM8/23/11
to David Mandelin
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.

Jeff Muizelaar

unread,
Aug 23, 2011, 11:26:19 AM8/23/11
to Mark Finkle, dev-pl...@lists.mozilla.org

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

Benjamin Stover

unread,
Aug 23, 2011, 12:03:34 PM8/23/11
to Jeff Muizelaar, Mark Finkle, dev-pl...@lists.mozilla.org
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


On Tue, Aug 23, 2011 at 8:26 AM, Jeff Muizelaar <jmuiz...@mozilla.com>wrote:

>
> 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
>

Matt Brubeck

unread,
Aug 23, 2011, 1:21:50 PM8/23/11
to
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?

Boris Zbarsky

unread,
Aug 23, 2011, 2:31:28 PM8/23/11
to
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

Boris Zbarsky

unread,
Aug 23, 2011, 2:32:12 PM8/23/11
to
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

azakai

unread,
Aug 23, 2011, 2:43:16 PM8/23/11
to
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

Ehsan Akhgari

unread,
Aug 23, 2011, 2:48:54 PM8/23/11
to Benjamin Smedberg, dev-pl...@lists.mozilla.org, dev-per...@lists.mozilla.org, David Mandelin
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

Axel Hecht

unread,
Aug 23, 2011, 5:18:06 PM8/23/11
to
On 23.08.11 13:13, Axel Hecht wrote:
>
> 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.

I was referring to
http://autonome.wordpress.com/2011/08/17/firefox-android-and-arming-the-world-with-the-open-web/,
fwiw.

Axel

Kadir Topal

unread,
Aug 23, 2011, 8:31:35 PM8/23/11
to Mark Finkle, dev-pl...@lists.mozilla.org

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

Taras Glek

unread,
Aug 23, 2011, 8:41:27 PM8/23/11
to L. David Baron, Robert O'Callahan, David Mandelin
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

Robert O'Callahan

unread,
Aug 23, 2011, 9:20:54 PM8/23/11
to Mark Finkle, dev-pl...@lists.mozilla.org
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! :-)

Mark Finkle

unread,
Aug 23, 2011, 9:23:15 PM8/23/11
to Robert Kaiser
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.

David Mandelin

unread,
Aug 23, 2011, 9:36:19 PM8/23/11
to

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

David Mandelin

unread,
Aug 23, 2011, 9:40:56 PM8/23/11
to
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

David Mandelin

unread,
Aug 23, 2011, 9:41:28 PM8/23/11
to
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

David Mandelin

unread,
Aug 23, 2011, 9:45:19 PM8/23/11
to
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

David Mandelin

unread,
Aug 23, 2011, 9:47:13 PM8/23/11
to
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

David Mandelin

unread,
Aug 23, 2011, 9:49:30 PM8/23/11
to
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

David Mandelin

unread,
Aug 23, 2011, 9:58:34 PM8/23/11
to
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

Boris Zbarsky

unread,
Aug 23, 2011, 10:04:42 PM8/23/11
to
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

David Mandelin

unread,
Aug 23, 2011, 10:05:19 PM8/23/11
to
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

L. David Baron

unread,
Aug 23, 2011, 11:02:26 PM8/23/11
to David Mandelin, dev-pl...@lists.mozilla.org
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/ 𝄂

Mark Finkle

unread,
Aug 23, 2011, 11:10:01 PM8/23/11
to David Mandelin
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.

Joe Drew

unread,
Aug 23, 2011, 11:17:55 PM8/23/11
to dev-pl...@lists.mozilla.org

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

Joe Drew

unread,
Aug 23, 2011, 11:21:35 PM8/23/11
to dev-pl...@lists.mozilla.org

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/

Mark Finkle

unread,
Aug 23, 2011, 11:22:41 PM8/23/11
to Kadir Topal, dev-pl...@lists.mozilla.org
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.

Jason Duell

unread,
Aug 23, 2011, 11:29:40 PM8/23/11
to dev-pl...@lists.mozilla.org

>> 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.

Mark Finkle

unread,
Aug 23, 2011, 11:31:20 PM8/23/11
to David Mandelin
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.

Benjamin Stover

unread,
Aug 23, 2011, 11:32:43 PM8/23/11
to Joe Drew, dev-pl...@lists.mozilla.org
This is what we're trying to do with mobile startup shrink--essentially
instant startup time. One more plug:
https://wiki.mozilla.org/Firefox/Projects/Mobile_Startup_Shrink

You can bugzilla search for mobilestartupshrink tags to see what we have so
far:
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=whiteboard%3Amobilestartupshrink&list_id=1160639

If you can help, please do! We hang out in #startup on IRC.

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. Maybe we could adjust function
timers to be much faster and enable them by default. Speaking of profiling
startup, our fab intern Jim Chen just posted some awesome systemtap results
here:
https://bugzilla.mozilla.org/attachment.cgi?id=554997&action=edit

Ben

> 1. https://lwn.net/Articles/**299483/ <https://lwn.net/Articles/299483/>
>
> ______________________________**_________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/dev-planning<https://lists.mozilla.org/listinfo/dev-planning>
>

Joe Drew

unread,
Aug 23, 2011, 11:38:15 PM8/23/11
to dev-pl...@lists.mozilla.org

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.

Benjamin Stover

unread,
Aug 23, 2011, 11:52:57 PM8/23/11
to dev-pl...@lists.mozilla.org
Disabled by default, but not removed:
http://mxr.mozilla.org/mozilla-central/ident?i=NS_TIME_FUNCTION

I'm repurposing my original profile bug for this purpose now:
https://bugzilla.mozilla.org/show_bug.cgi?id=675233

Ben

Justin Lebar

unread,
Aug 24, 2011, 12:57:26 AM8/24/11
to
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.

Nicholas Nethercote

unread,
Aug 24, 2011, 1:11:09 AM8/24/11
to mozilla.de...@googlegroups.com, dev-pl...@lists.mozilla.org
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

L. David Baron

unread,
Aug 23, 2011, 11:27:16 PM8/23/11
to Taras Glek, Robert O'Callahan, David Mandelin
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

Wesley Johnston

unread,
Aug 24, 2011, 1:20:28 AM8/24/11
to David Mandelin, dev-pl...@lists.mozilla.org
> 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

Mike Hommey

unread,
Aug 24, 2011, 2:46:25 AM8/24/11
to David Mandelin, dev-pl...@lists.mozilla.org
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

Mike Hommey

unread,
Aug 24, 2011, 3:12:38 AM8/24/11
to David Mandelin, dev-pl...@lists.mozilla.org
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

Martijn

unread,
Aug 24, 2011, 3:34:55 AM8/24/11
to Joe Drew, dev-pl...@lists.mozilla.org
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

Gervase Markham

unread,
Aug 24, 2011, 5:39:31 AM8/24/11
to
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

Gervase Markham

unread,
Aug 24, 2011, 5:39:36 AM8/24/11
to
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

James May

unread,
Aug 24, 2011, 7:26:41 AM8/24/11
to dev-pl...@lists.mozilla.org
Of course some might argue that every platform should have a separate UI...

I'd be most interested in the results of the B2G HTML UI work.

> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>

--
James May

Patrick McManus

unread,
Aug 24, 2011, 9:16:16 AM8/24/11
to Joe Drew, dev-pl...@lists.mozilla.org
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.

Mike Hommey

unread,
Aug 24, 2011, 9:19:42 AM8/24/11
to Patrick McManus, Joe Drew, dev-pl...@lists.mozilla.org

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

Robert Accettura

unread,
Aug 24, 2011, 9:32:16 AM8/24/11
to Mike Hommey, Joe Drew, Patrick McManus, dev-pl...@lists.mozilla.org

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

Patrick McManus

unread,
Aug 24, 2011, 9:38:47 AM8/24/11
to Mike Hommey, Joe Drew, dev-pl...@lists.mozilla.org
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.

Robert Kaiser

unread,
Aug 24, 2011, 9:47:17 AM8/24/11
to
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! :)

Robert Kaiser

unread,
Aug 24, 2011, 9:49:00 AM8/24/11
to
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?

Mike Hommey

unread,
Aug 24, 2011, 9:55:18 AM8/24/11
to Robert Accettura, Joe Drew, Patrick McManus, dev-pl...@lists.mozilla.org
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

Mike Shaver

unread,
Aug 24, 2011, 10:04:11 AM8/24/11
to Mike Hommey, Joe Drew, Patrick McManus, dev-pl...@lists.mozilla.org, Robert Accettura

We speculatively pre-fetch CSS, JS and images ahead of the parser's
full progress, since 3.5. In 4 we also continue parsing the HTML
document across blocking loads, which helps find more things to
speculatively pre-fetch.

https://developer.mozilla.org/en/HTML/Optimizing_Your_Pages_for_Speculative_Parsing

Mike

Robert Kaiser

unread,
Aug 24, 2011, 10:13:06 AM8/24/11
to
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 Accettura

unread,
Aug 24, 2011, 10:28:21 AM8/24/11
to Mike Shaver, Joe Drew, Mike Hommey, dev-pl...@lists.mozilla.org, Patrick McManus

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.

Kadir Topal

unread,
Aug 24, 2011, 12:17:02 PM8/24/11
to Mark Finkle, dev-pl...@lists.mozilla.org

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

Michael Verdi

unread,
Aug 24, 2011, 12:20:34 PM8/24/11
to David Mandelin, dev-pl...@lists.mozilla.org
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

Mike Hommey

unread,
Aug 24, 2011, 12:48:34 PM8/24/11
to Michael Verdi, dev-pl...@lists.mozilla.org, David Mandelin

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

Michael Verdi

unread,
Aug 24, 2011, 1:13:25 PM8/24/11
to Mike Hommey, dev-pl...@lists.mozilla.org, David Mandelin
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.firefox
https://input.mozilla.com/en-US/?q=slow&product=mobile&version=--&sentiment=happy&locale=en-US

- Michael

Mike Hommey

unread,
Aug 24, 2011, 1:21:44 PM8/24/11
to Michael Verdi, dev-pl...@lists.mozilla.org, David Mandelin

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

Mike Hommey

unread,
Aug 24, 2011, 1:22:30 PM8/24/11
to Michael Verdi, dev-pl...@lists.mozilla.org, David Mandelin

(for cold startup, that is)

Mike

Michael Verdi

unread,
Aug 24, 2011, 1:42:15 PM8/24/11
to Mike Hommey, dev-pl...@lists.mozilla.org, David Mandelin
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

Benjamin Stover

unread,
Aug 24, 2011, 2:24:33 PM8/24/11
to dev-pl...@lists.mozilla.org
It is time for another startup shrink meeting! We need help fixing bugs and
profiling, so please come and weigh in. Don't be afraid to think big,
especially if you can prototype something interesting! :)

Time: 9:30AM PDT
Date: Tuesday 8/30
Phone Ext: #8604
Vidyo Room: Benjamin Stover (9045)

Let me know if there are any conflicts and you wish to attend.

Ben

On Wed, Aug 24, 2011 at 10:21 AM, Mike Hommey <m...@glandium.org> wrote:

> On Wed, Aug 24, 2011 at 12:13:25PM -0500, Michael Verdi 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.firefox
> >
> https://input.mozilla.com/en-US/?q=slow&product=mobile&version=--&sentiment=happy&locale=en-US
>
> 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

Ron Hunter

unread,
Aug 24, 2011, 2:48:51 PM8/24/11
to

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.

Ron Hunter

unread,
Aug 24, 2011, 2:51:48 PM8/24/11
to
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.

Kadir Topal

unread,
Aug 24, 2011, 3:04:52 PM8/24/11
to Ron Hunter, dev-pl...@lists.mozilla.org

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

Steve Fink

unread,
Aug 24, 2011, 3:54:31 PM8/24/11
to dev-pl...@lists.mozilla.org
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

Mark Finkle

unread,
Aug 24, 2011, 4:22:33 PM8/24/11
to David Mandelin
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

Boris Zbarsky

unread,
Aug 24, 2011, 5:15:54 PM8/24/11
to
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

Ron Hunter

unread,
Aug 24, 2011, 5:30:57 PM8/24/11
to

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.

Mark Finkle

unread,
Aug 24, 2011, 7:00:31 PM8/24/11
to Boris Zbarsky
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

Mark Finkle

unread,
Aug 24, 2011, 7:08:06 PM8/24/11
to Boris Zbarsky

David Mandelin

unread,
Aug 24, 2011, 9:55:04 PM8/24/11
to
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

David Mandelin

unread,
Aug 24, 2011, 9:59:11 PM8/24/11
to
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

David Mandelin

unread,
Aug 24, 2011, 10:07:34 PM8/24/11
to

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

Mark Finkle

unread,
Aug 24, 2011, 10:16:03 PM8/24/11
to David Mandelin

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.

David Mandelin

unread,
Aug 24, 2011, 10:20:07 PM8/24/11
to
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

L. David Baron

unread,
Aug 24, 2011, 10:39:29 PM8/24/11
to Mark Finkle, dev-pl...@lists.mozilla.org
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/ 𝄂

Robert O'Callahan

unread,
Aug 25, 2011, 1:40:59 AM8/25/11
to Michael Verdi, dev-pl...@lists.mozilla.org, David Mandelin
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
>

Mike Hommey

unread,
Aug 25, 2011, 2:01:05 AM8/25/11
to Robert O'Callahan, Michael Verdi, dev-pl...@lists.mozilla.org, David Mandelin
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

Mike Hommey

unread,
Aug 25, 2011, 2:11:17 AM8/25/11
to Michael Verdi, dev-pl...@lists.mozilla.org, David Mandelin
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

Gervase Markham

unread,
Aug 25, 2011, 6:38:05 AM8/25/11
to
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

Robert Kaiser

unread,
Aug 25, 2011, 9:30:01 AM8/25/11
to
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! :)

Robert Kaiser

unread,
Aug 25, 2011, 9:34:55 AM8/25/11
to
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?

It is loading more messages.
0 new messages