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

classic Classic list List threaded Threaded
155 messages Options
1234 ... 8
Reply | Threaded
Open this post in threaded view
|

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

Dave Mandelin-2
(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
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Matt Brubeck-3
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.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Boris Zbarsky
In reply to this post by Dave Mandelin-2
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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Jonas Sicking-2
In reply to this post by Matt Brubeck-3
On Mon, Aug 22, 2011 at 7:47 PM, Matt Brubeck <[hidden email]> wrote:

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

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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Matt Brubeck-3
In reply to this post by Dave Mandelin-2
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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Justin Lebar-3
In reply to this post by Boris Zbarsky
>> 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.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Matt Brubeck-3
In reply to this post by Matt Brubeck-3
>> 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.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Robert O'Callahan-3
In reply to this post by Dave Mandelin-2
Great write-up!

On Tue, Aug 23, 2011 at 1:18 PM, David Mandelin <[hidden email]>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]
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

L. David Baron
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 <[hidden email]>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/   𝄂
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Mike Hommey
In reply to this post by Dave Mandelin-2
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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Axel Hecht
In reply to this post by Dave Mandelin-2
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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Kyle Huey-2
In reply to this post by Dave Mandelin-2
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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Ali Juma
In reply to this post by Matt Brubeck-3

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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Ludovic Hirlimann-4
In reply to this post by Dave Mandelin-2
On 23/08/11 03:18, David Mandelin wrote:

> (Oops--posted this to mozilla.dev.performance and dev-planning@lists by
> mistake--I meant to post in dev.planning both ways. Please add the list
> to followups to keep conversation together.)
>
> I've been thinking a bit about what can do, and what we need to do, for
> Firefox performance on mobile devices. 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.

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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Robert Kaiser
In reply to this post by Dave Mandelin-2
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! :)
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Robert Kaiser
In reply to this post by Matt Brubeck-3
Jonas Sicking schrieb:
> Note that non-XUL doesn't need to mean non-Gecko. One option is to
> build a front-end in HTML. I think the HTML code has received a lot
> more performance love than the XUL code in many areas.

I think that HTML still needs some love to measure up to XUL in terms of
using it for UI, but starting with converting Fennec UI over might be
the right thing because it has relatively little UI compared to
everything else and improving HTML for the things needed there is
probably a good start.

Robert Kaiser


--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community should think about. And most of the
time, I even appreciate irony and fun! :)
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Benjamin Smedberg
In reply to this post by Dave Mandelin-2
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

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Mark Finkle
In reply to this post by Dave Mandelin-2
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.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Jeff Muizelaar-4

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

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Benjamin Stover-2
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 <[hidden email]>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
>
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
>
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
1234 ... 8