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

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.

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

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

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

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

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

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

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.

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]

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

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)

>  - unknown needlessly parsing XML, CSS, etc.

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

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

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

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

>   - 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! :)

> 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! :)

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.

>
>
> Taras also said that Alon Zakai told him IPC overhead between main and
> content processes is hurting us here.

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

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.

* 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

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.

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

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:

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

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?

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

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

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

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

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

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

Axel

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

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

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

On my Nexus S, startup is about 2s to showing the browser window, then maybe
another 1s before the home screen is fully visible. I'm shocked it's 5s for
some people! :-)

Rob
--
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]

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.

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

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

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

I'm definitely looking forward to that bug.

Dave

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

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

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.

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

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

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

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

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

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

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

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.

> 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

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

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.

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

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/

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

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

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.

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

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.

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

Ben

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

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.

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

On Tuesday 2011-08-23 17:41 -0700, Taras Glek wrote:
> On 08/22/2011 09:07 PM, L. David Baron wrote:
> >On Tuesday 2011-08-23 15:32 +1200, Robert O'Callahan wrote:
> >>Great write-up!
> >>
> >>On Tue, Aug 23, 2011 at 1:18 PM, David Mandelin<dman...@mozilla.com>wrote:
> >>
> >>>- 0.5s XUL reflows
> >>>
> >>
> >>We should be able to fix this in layout. The old XUL flexbox code is pretty
> >>crazy but Daniel Holbert has a new implementation of CSS3 flexbox that
> >>should be better. It would be helpful if someone imported the Fennec UI into
> >>a standalone test page for easy performance analysis.
> >
> >I suspect this isn't actually reflow, though.  In XUL documents a
> >lot of stuff, including frame construction and style resolution,
> >happens inside of PresShell::InitialReflow.  The previous times I've
> >seen reflow accused of being this portion of a profile, it was
> >actually "all the stuff inside PresShell::InitialReflow" being
> >accused.
>
> Here is what I'm using to measure. You are right about 200-300ms of
> that is initial reflow + a further 50-300ms (not sure why it varies
> so much) for further reflows. I still think the total cost here
> should be closer to 0 than it is right now.
>
> I filed regarding adding these measurements to telemetry
> https://bugzilla.mozilla.org/show_bug.cgi?id=681535

So the measurements in that bug are going to measure a lot more than
just Reflow, last I checked, particularly for XUL (where, if my
memory is correct, we don't do incremental layout and all frame
construction and style resolution happens within
PresShell::InitialReflow).  And, actually, now that I look at the
code, no reflow actually even happens inside of
PresShell::InitialReflow, since it just posts a reflow event (see
bug 378975).

Even if that patch is fixed to only measure ProcessReflowCommands
(which is a reasonable point for measuring time spent within
reflow), it's still subject to dealing with laziness within layout
(see below).

This sort of function-timing telemetry has to be accompanied by some
profiling of what happens inside the time that you're measuring.
Otherwise you don't know what it is that needs to be fixed.

> >*Lots* of stuff in layout happens lazily, so if you want to break
> >down time spent in style vs. frame construction vs. reflow, you
> >really need to split profiles using a tool like
> >http://mxr.mozilla.org/mozilla-central/source/tools/jprof/split-profile.pl
> >For more details, see my posts on 2010-05-06 to dev.platform in the
> >thread "Startup Timeline - Can you help?" which unfortunately are
> >not archived on google groups as far as I can tell.
>
> I didn't see anything particularly enlightening in that thread.

Basically, there are a large number of things in layout that happen
lazily.  Some information becomes invalid, and instead of
recomputing it immediately, we just mark it invalid.  This is
important because there might be 100 different things that mark it
invalid before we next actually need the information.  Then, when we
need the information, we (re)compute it.

This makes attributing blame to a particular subsystem within layout
(e.g., CSS cascading, CSS selector matching, font matching, style
computation, frame construction, reflow/layout) more complicated
than just timing the duration of a particular function.  The only
accurate way I know to do this is to take a profile and slice it
into sets, starting by slicing out the leaf-most actions (i.e., the
ones that don't nest any other things), and then the ones that only
nest inside of them the things already sliced out, etc.  This is
what split-profile.pl does.  Getting these splits correct requires
looking at the profile data within each split to make sure it
represents a single task.

An example (very out-of-date, but quite accurate at the time) set of
splitting rules is provided within this attachment:
https://bugzilla.mozilla.org/show_bug.cgi?id=144533#c40

-David

--
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla Corporation               http://www.mozilla.com/   𝄂

> 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

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

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

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

--
Martijn Wargers - Help Mozilla!
http://quality.mozilla.org/
http://wiki.mozilla.org/Mozilla_QA_Community
irc://irc.mozilla.org/qa - /nick mw22

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

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

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

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.

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

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

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.

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! :)

Argh, yes, HTML is badly missing something like the overlay system. Any
way to get something in that style into HTML?

Robert Kaiser

--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community should think about. And most of the
time, I even appreciate irony and fun! :)

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

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

AFAIK, even the SDK- or Jetpack-based add-ons heavily rely on having the
ability of DOM manipulations and HTML-based UI controls.

Robert Kaiser

--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community should think about. And most of the
time, I even appreciate irony and fun! :)

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.

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

--
I work on support
irc: verdi

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

Mike Hommey wrote:
> There is absolutely no way we can get as fast as the "native" browser

- Michael

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

(for cold startup, that is)

Mike

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

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

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

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

Maybe you're thinking of the timeline, which was indeed removed -
https://bugzilla.mozilla.org/show_bug.cgi?id=579571

> 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

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

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.

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

On 08/24/2011 07:00 PM, Mark Finkle wrote:
> On 08/24/2011 05:15 PM, Boris Zbarsky wrote:
>> On 8/24/11 4:22 PM, Mark Finkle wrote:

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

Filed https://bugzilla.mozilla.org/show_bug.cgi?id=681815

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

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

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

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.

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

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

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
>

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

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

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

> 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! :)

I've just updated the version on my N900 from a Aug 02 (8.0a1) Nightly
to a current (9.0a1) Nightly, and it feels like a significant jump in
performance to me. I know from 6 to 8, we improved, and this month, we
seem to have done even more. As our primary focus is not my old maemo5
device but Android, I'd expect the effects to be even larger there -
have you tested what difference you feel on your side there?

Robert Kaiser

--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community should think about. And most of the
time, I even appreciate irony and fun! :)

On 2011-08-24 18:20, Michael Verdi wrote:
> David Mandelin wrote:
>>
>> Secondary Goals:
>>
>> B5. Improve startup time.
>>
>> B6. Improve pageload time.
>>
> Personally, I think these should be the #1 priority. Like the, stop
> everything and fix this kind of number one. The vast majority of my
> interactions with a browser on my phone is following a link from email,
> twitter, facebook or any number of apps (may be the case for many users
> too http://mzl.la/n2omLK ). If Firefox has to cold start it's painful.
> And the thing is, it has to cold start all of the time. I can't tell you
> how many times a day I see that logo (6? 8?). It's making me start to
> hate the logo. Here's a quick comparison that I did on my HTC Desire HD.
> I follow a link to a blog from twitter. I quit both browsers before
> doing the test. As a bonus you get to see that when I do get the page
> loaded the default tap-to-zoom on Firefox is not much help.
> http://people.mozilla.org/~mverdi/video/mobile-comparison.webm

Really good video that summarizes two of the main issues I see with
Fennec today. Although speed improvements are critical and will to some
extent get better as hardware becomes faster, a far more Fennec-specific
issue is the way zooming is handled. As can be seen on this video, you
can't actually read the text on a stock Fennec install.

On 08/24/2011 10:40 PM, Robert O'Callahan wrote:
> If following links is super-common, maybe we could optimize for that
> explicitly by getting just that page up and loading browser chrome later.

We already do this to some extent; we wait until the first page load
completes and then fire a "UIReadyDelayed" event.  Much of our chrome
initialization starts at that event.  If you try to open the preference
panels before that first page load is done, you can actually watch them
initialize.

Our mobile Ts benchmark measures the time to the end of the first page
load.  Delaying chrome initialization is one of the main ways we've
improved performance on that benchmark.

On 08/25/2011 09:59 AM, David Tenser wrote:
> On 2011-08-24 18:20, Michael Verdi wrote:

>> Personally, I think these should be the #1 priority. Like the, stop
>> everything and fix this kind of number one. The vast majority of my
>> interactions with a browser on my phone is following a link from email,
>> twitter, facebook or any number of apps (may be the case for many users
>> too http://mzl.la/n2omLK ). If Firefox has to cold start it's painful.
>> And the thing is, it has to cold start all of the time. I can't tell you
>> how many times a day I see that logo (6? 8?). It's making me start to
>> hate the logo. Here's a quick comparison that I did on my HTC Desire HD.
>> I follow a link to a blog from twitter. I quit both browsers before
>> doing the test. As a bonus you get to see that when I do get the page
>> loaded the default tap-to-zoom on Firefox is not much help.
>> http://people.mozilla.org/~mverdi/video/mobile-comparison.webm
>
> Really good video that summarizes two of the main issues I see with
> Fennec today. Although speed improvements are critical and will to some
> extent get better as hardware becomes faster, a far more Fennec-specific
> issue is the way zooming is handled. As can be seen on this video, you
> can't actually read the text on a stock Fennec install.

Work is happening to improve this. Watch this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=627842

Building on what Matt talks about, we do have some data on startup time
in the field. Firefox (desktop and mobile) send some startup time
performance data to AMO along with the daily add-ons ping. Mozilla uses
that to gauge the affect of add-ons on startup time.

For mobile, we can use it to get an idea of the range of startup times
happening in the field. I did a post using the data back in Fx 4 timeframe:
http://starkravingfinkle.org/blog/2011/02/firefox-4-for-mobile-beta-5-performance-improvements/

I pulled the latest graphs for Fx7:
http://people.mozilla.com/~mfinkle/fennec/startup-time-general-7.0.png
http://people.mozilla.com/~mfinkle/fennec/startup-time-median-7.0.png

You can see we have improved a bit since Fx4, but the range of startup
times is still fairly poor and should be improved. Ben Stover's
StartupShrink project has come up with a few mini project ideas.

We have talked a bit about the affect of XUL and UI on the startup time,
but I would call attention the the "tMain" line in the charts. That's
how long it takes to get to the main() function from the time the
process is started by the OS.

David Tenser wrote:
> Really good video that summarizes two of the main issues I see with
> Fennec today. Although speed improvements are critical and will to some
> extent get better as hardware becomes faster, a far more Fennec-specific
> issue is the way zooming is handled. As can be seen on this video, you
> can't actually read the text on a stock Fennec install.

I don't use smartphones so I can't comment much about the readability
issues there but I don't find the zoom thing to be any barrier to using
Fennec on tablet with decent resolution.

- A

On Thu, Aug 25, 2011 at 10:28:11AM -0400, Mark Finkle wrote:
> On 08/25/2011 10:11 AM, Matt Brubeck wrote:
> >On 08/24/2011 10:40 PM, Robert O'Callahan wrote:
> >>If following links is super-common, maybe we could optimize for that
> >>explicitly by getting just that page up and loading browser chrome later.
> >
> >We already do this to some extent; we wait until the first page load
> >completes and then fire a "UIReadyDelayed" event. Much of our chrome
> >initialization starts at that event. If you try to open the preference
> >panels before that first page load is done, you can actually watch them
> >initialize.
> >
> >Our mobile Ts benchmark measures the time to the end of the first page
> >load. Delaying chrome initialization is one of the main ways we've
> >improved performance on that benchmark.
>
> Building on what Matt talks about, we do have some data on startup
> time in the field. Firefox (desktop and mobile) send some startup
> time performance data to AMO along with the daily add-ons ping.
> Mozilla uses that to gauge the affect of add-ons on startup time.
>
> For mobile, we can use it to get an idea of the range of startup
> times happening in the field. I did a post using the data back in Fx
> 4 timeframe:
> http://starkravingfinkle.org/blog/2011/02/firefox-4-for-mobile-beta-5-performance-improvements/
>
> I pulled the latest graphs for Fx7:
> http://people.mozilla.com/~mfinkle/fennec/startup-time-general-7.0.png
> http://people.mozilla.com/~mfinkle/fennec/startup-time-median-7.0.png

What does the second graph represent on the horizontal axis?

> You can see we have improved a bit since Fx4, but the range of
> startup times is still fairly poor and should be improved. Ben
> Stover's StartupShrink project has come up with a few mini project
> ideas.

It however raises a question: is the improvement for the most on our
part, or for the most because more and more of our users are using
faster devices?

Mike

On 08/25/2011 11:32 AM, Mike Hommey wrote:
> On Thu, Aug 25, 2011 at 10:28:11AM -0400, Mark Finkle wrote:

>> For mobile, we can use it to get an idea of the range of startup
>> times happening in the field. I did a post using the data back in Fx
>> 4 timeframe:
>> http://starkravingfinkle.org/blog/2011/02/firefox-4-for-mobile-beta-5-performance-improvements/
>>
>> I pulled the latest graphs for Fx7:
>> http://people.mozilla.com/~mfinkle/fennec/startup-time-general-7.0.png
>> http://people.mozilla.com/~mfinkle/fennec/startup-time-median-7.0.png
>
> What does the second graph represent on the horizontal axis?

Time. Each version of Firefox sends data each day. So what you see is
daily data collected for Firefox 7.

>> You can see we have improved a bit since Fx4, but the range of
>> startup times is still fairly poor and should be improved. Ben
>> Stover's StartupShrink project has come up with a few mini project
>> ideas.
>
> It however raises a question: is the improvement for the most on our
> part, or for the most because more and more of our users are using
> faster devices?

Very true

On Thu, Aug 25, 2011 at 11:35:26AM -0400, Mark Finkle wrote:
> On 08/25/2011 11:32 AM, Mike Hommey wrote:
> >On Thu, Aug 25, 2011 at 10:28:11AM -0400, Mark Finkle wrote:
>
> >>For mobile, we can use it to get an idea of the range of startup
> >>times happening in the field. I did a post using the data back in Fx
> >>4 timeframe:
> >>http://starkravingfinkle.org/blog/2011/02/firefox-4-for-mobile-beta-5-performance-improvements/
> >>
> >>I pulled the latest graphs for Fx7:
> >>http://people.mozilla.com/~mfinkle/fennec/startup-time-general-7.0.png
> >>http://people.mozilla.com/~mfinkle/fennec/startup-time-median-7.0.png
> >
> >What does the second graph represent on the horizontal axis?
>
> Time. Each version of Firefox sends data each day. So what you see
> is daily data collected for Firefox 7.

So that's 4 days worth? with tMain improvements every day ?

Mike

On 08/25/2011 11:47 AM, Mike Hommey wrote:

>> Time. Each version of Firefox sends data each day. So what you see
>> is daily data collected for Firefox 7.
>
> So that's 4 days worth? with tMain improvements every day ?

4 days worth of Firefox 7 for Mobile data. Just normal variances in data
because of population changes.

On 8/24/11 7:20 PM, David Mandelin wrote:
> On 8/23/2011 10:20 PM, Wesley Johnston wrote:
>>> I think I agree, but I'm not sure yet. Opera has a feature where if you
>>> scroll fast, they show a button with an up or down arrow that will
>>> scroll you all the way, which I thought was just generally neat, but
>>> they might also have added it to mitigate their slower scrolling.
>> We actually have a feature in Fennec where two finger up or down swipes
>> will take you to the top and bottom of documents (left and right move back
>> and forward in history),
> Hey, cool! I've been wanting some feature that did that, and I didn't
> know we had that. Do our users know? How do we teach them?
>

Just register and then edit the wiki any time you have a solution you
want to document or improve.

On the larger topic of performance, we also need an article for the
short-term to help folks sort out why Firefox for Mobile is slow, so I
started a troubleshooting article for that problem here:
https://support.mozilla.com/en-US/kb/why-firefox-mobile-slow/revision/16686

Let me know what you think.

Thanks,
Michelle Luna
Firefox for Mobile Support
http://www.meetup.com/Firefox-Android-superheroes/

On 08/25/2011 07:28 AM, Mark Finkle wrote:
> On 08/25/2011 10:11 AM, Matt Brubeck wrote:
>> On 08/24/2011 10:40 PM, Robert O'Callahan wrote:
>>> If following links is super-common, maybe we could optimize for that
>>> explicitly by getting just that page up and loading browser chrome
>>> later.
>>
>> We already do this to some extent; we wait until the first page load
>> completes and then fire a "UIReadyDelayed" event. Much of our chrome
>> initialization starts at that event. If you try to open the preference
>> panels before that first page load is done, you can actually watch them
>> initialize.
>>
>> Our mobile Ts benchmark measures the time to the end of the first page
>> load. Delaying chrome initialization is one of the main ways we've
>> improved performance on that benchmark.
>
> Building on what Matt talks about, we do have some data on startup
> time in the field. Firefox (desktop and mobile) send some startup time
> performance data to AMO along with the daily add-ons ping. Mozilla
> uses that to gauge the affect of add-ons on startup time.

Do you get information about memory installed or CPU? It'd be
interesting to see a scatterplot of memory vs startup time. (Maybe
available memory at the time Firefox is launched? Is that collectible,
or perhaps not meaningful because it'll trigger memory-pressure events
to all other apps?)

On 08/25/2011 02:13 PM, Steve Fink wrote:
> On 08/25/2011 07:28 AM, Mark Finkle wrote:

>> Building on what Matt talks about, we do have some data on startup
>> time in the field. Firefox (desktop and mobile) send some startup time
>> performance data to AMO along with the daily add-ons ping. Mozilla
>> uses that to gauge the affect of add-ons on startup time.
>
> Do you get information about memory installed or CPU? It'd be
> interesting to see a scatterplot of memory vs startup time. (Maybe
> available memory at the time Firefox is launched? Is that collectible,
> or perhaps not meaningful because it'll trigger memory-pressure events
> to all other apps?)

The AMO pings do not get the device data, but Zippity
(http://zippityserver.appspot.com) and Telemetry do. We do not send
"installed RAM", but using the device ID we could create a lookup.

> I've been thinking a bit about what can do, and what we need to do, for
> Firefox performance on mobile devices. This is really just a start, but
> I think it points the way for the performance efforts we have to make to
> make Firefox just as great on Android/ARM as it is on desktop. I give an
> evaluation of performance today, recommendations for top performance
> goals, some big changes we might need, and last, a draft plan, really
> just a sketch, of the way forward.

I'd like to propose that Mozilla changes the way we develop the
platform. Instead of developing platform changes first on desktop and
then trickling down to mobile, we should reverse that.

We should have all platform development happen first using mobile
hardware (tablets and phones). So all initial coding, profiling and
debugging happens on mobile. Once the code passes the quality and
performance levels needed for mobile, we can then get desktop
implementations ready (where separate desktop impls are actually needed).

That might help with situations where features land and work well on
desktop, but don't really meet expectations on mobile. Currently, we
would file a bug to get the platform devs to try to improve the
situation on mobile. Most of the time, the platform devs _do_ try get
fixes for mobile, but sometimes we don't get a fix landed in a timely
manner, if at all.

There are improve-for-mobile bugs currently waiting for dev resources.

I propose the Mobile First idea for the entire platform development team
and not just create smaller subset teams to focus on mobile.

I focus on the platform team, but other teams should also adopt the
strategy too. Desktop and Mobile Firefox have front-end teams that focus
on UI for the respective products. I'm not sure how a Mobile First
approach would affect those teams.

Thoughts?

On 25 Aug 2011, at 21:55, Mark Finkle wrote:

> I'd like to propose that Mozilla changes the way we develop the platform. Instead of developing platform changes first on desktop and then trickling down to mobile, we should reverse that.
>
> We should have all platform development happen first using mobile hardware (tablets and phones). So all initial coding, profiling and debugging happens on mobile. Once the code passes the quality and performance levels needed for mobile, we can then get desktop implementations ready (where separate desktop impls are actually needed).

Interesting approach!

Offhand, I do have a couple reservations, though... Are the mobile development tools (coding and debugging environments, profiling tools, etc) really up to the level where we could do this without seriously impacting developer productivity? Also, I think the experience of "dogfooding" our own builds, including our own work-in-progress patches, provides significant "instant feedback" to platform developers - do you expect that we'd all switch to using mobile devices as our primary web-browsing environments? If not, we'd lose much of that hands-on real-life experience.

JK

On Thu, Aug 25, 2011 at 4:55 PM, Mark Finkle <mark....@gmail.com> wrote:
> We should have all platform development happen first using mobile hardware
> (tablets and phones). So all initial coding, profiling and debugging happens
> on mobile. Once the code passes the quality and performance levels needed
> for mobile, we can then get desktop implementations ready (where separate
> desktop impls are actually needed).

It's a nice thought experiment, and I've tried to push that rock up
the hill a few times, but it always gets stuck on things like:

- what profiling? last time I asked about how I profiled on my phone I
was told to build a custom ROM, IIRC, and I couldn't do that from
anything but a Linux VM.  The Android toolchain is much more painful
to work with (debugger!) than any of our desktop platforms, and I
think that the productivity hit would be very substantial.

- unless things have dramatically improved since I last compared, the
test coverage is much much lower on mobile than on desktop, and I
haven't seen the mobile-expert resources pointed at solving that in an
effective way so far.

- try server + android = oof

We're already hurting from developer ergonomic issues around
turn-around time.  I just don't think that Firefox on Android is ready
to be the primary developer target, though it would be great if it
were.

I agree that we shouldn't have an isolated mobile group chasing
desktop platform or browser improvements; a theme of mine for a couple
of years, in fact, and I'm very glad that Damon has been able to make
progress on it where I couldn't.  But I think that the way to make
progress on that now is to spread the mobile knowledge through the
existing platform and application teams, and project their expertise
into discussions about gfx/networking/whatever.

Something I don't understand: what are you seeing happen these days
that doesn't meet the mobile performance targets?  How do you
determine it's the case (Talos?), and why does it differ meaningfully?
 Other than a very small number of things that are processor-specific,
are there patterns around cache or I/O that are problematic, which we
could address as an easier step?

Mike

On Thu, Aug 25, 2011 at 5:11 PM, Jonathan Kew <jfkt...@googlemail.com> wrote:
> Also, I think the experience of "dogfooding" our own builds, including our own work-in-progress patches, provides significant "instant feedback" to platform developers - do you expect that we'd all switch to using mobile devices as our primary web-browsing environments? If not, we'd lose much of that hands-on real-life experience.

Yeah, I don't think we're there yet.  There are a bunch of (known,
being-worked-on) things around text editing and zooming, for example,
which makes working with bugzilla pretty unproductive.  I've tried,
but I can't live in my phone for the stuff I do (zimbra, twitter-web,
gmail-web, facebook-web, etc.), at least yet.

Mike

On 08/25/2011 05:11 PM, Jonathan Kew wrote:
> On 25 Aug 2011, at 21:55, Mark Finkle wrote:
>
>> I'd like to propose that Mozilla changes the way we develop the platform. Instead of developing platform changes first on desktop and then trickling down to mobile, we should reverse that.
>>
>> We should have all platform development happen first using mobile hardware (tablets and phones). So all initial coding, profiling and debugging happens on mobile. Once the code passes the quality and performance levels needed for mobile, we can then get desktop implementations ready (where separate desktop impls are actually needed).
>
> Interesting approach!
>
> Offhand, I do have a couple reservations, though... Are the mobile development tools (coding and debugging environments, profiling tools, etc) really up to the level where we could do this without seriously impacting developer productivity?

debugging is getting better, but only got better when platform devs
focused on making it better. Profiling is the same way. Work is being
done related to B2G for profiling and I think this could be moved faster
with the extra focus and support fo dozens of devs.

 > Also, I think the experience of "dogfooding" our own builds,
including our own work-in-progress patches, provides significant
"instant feedback" to platform developers - do you expect that we'd all
switch to using mobile devices as our primary web-browsing environments?
If not, we'd lose much of that hands-on real-life experience.

This is certainly true, but we need to start the process somewhere.
Trying to do any amount of "living" on your tablet would be a great
improvement to our current dogfooding and would find a lot of low
hanging fruit.

On Thu, Aug 25, 2011 at 5:30 PM, Mark Finkle <mark....@gmail.com> wrote:
> debugging is getting better, but only got better when platform devs focused
> on making it better. Profiling is the same way.

what platform work was needed here? I thought it was all
toolchain-side stuff that was hurting. (that's certainly where I got
stumped a bunch of times.)

Mike

On 08/25/2011 05:13 PM, Mike Shaver wrote:
> On Thu, Aug 25, 2011 at 4:55 PM, Mark Finkle<mark....@gmail.com>  wrote:
>> We should have all platform development happen first using mobile hardware
>> (tablets and phones). So all initial coding, profiling and debugging happens
>> on mobile. Once the code passes the quality and performance levels needed
>> for mobile, we can then get desktop implementations ready (where separate
>> desktop impls are actually needed).
>
> It's a nice thought experiment, and I've tried to push that rock up
> the hill a few times, but it always gets stuck on things like:
>
> - what profiling? last time I asked about how I profiled on my phone I
> was told to build a custom ROM, IIRC, and I couldn't do that from
> anything but a Linux VM.  The Android toolchain is much more painful
> to work with (debugger!) than any of our desktop platforms, and I
> think that the productivity hit would be very substantial.

Very true, but debugging seems to be improving a lot. Jim Chen build a
custom GDB that is state of the art. Profiling is also moving along and
if we can't find ways to profile using oprofile, we'll need to find or
invent other ways. I have seen Mozilla do amazing things. Lack of an
existing profiler will not stop the people I work with.

> - unless things have dramatically improved since I last compared, the
> test coverage is much much lower on mobile than on desktop, and I
> haven't seen the mobile-expert resources pointed at solving that in an
> effective way so far.
>
> - try server + android = oof

This is getting better too. Everyday we find issues with the tegras
(dammit) and find ways to fix them too. We are looking to bring panda
boards online as well, so we can mix up the hardware a bit. Maybe
finding a better hardware platform to use, since the tegras are not even
supported by nVidia anymore.

We can even run many of our tests from a local machine using ADB and
your own phone or tablet! Amazing I know.

> Something I don't understand: what are you seeing happen these days
> that doesn't meet the mobile performance targets?  How do you
> determine it's the case (Talos?), and why does it differ meaningfully?
>   Other than a very small number of things that are processor-specific,
> are there patterns around cache or I/O that are problematic, which we
> could address as an easier step?

Talos is a good general tool to look for regressions, but I have seen
Mozilla devs fallback to simple timing helpers in the code, dumping to
stdout as well. And we are not in a regression-watching situation as
much as a make-it-faster situation. Things like rendering alpha blurs on
ARM are too slow. Forcing reflows when an element is moving in a stack
is not cool. I pick these examples cause I know we have bugs filed and
patches waiting to improve them.

You once told me the Mozilla/Firefox 1.0 improved performance 1% at a
time, by any means necessary :)

On Thu, Aug 25, 2011 at 5:38 PM, Mark Finkle <mark....@gmail.com> wrote:
> You once told me the Mozilla/Firefox 1.0 improved performance 1% at a time,
> by any means necessary :)

I gotta keep my mouth shut.

So I agree that we (everyone, even non-engineers) need to get to the
point that making Android your primary development environment is as
credible a choice as Linux on a laptop.  Once we're there, maybe we
can look at making it mandatory, but I have some skepticism about how
well that'll actually work.

Mike

I see our platform devs do amazing things, like Jim Chen taking GDB and
getting it bleeding edge for Android,

For profiling, I am thinking about tools like Patrick Walton's Piranha:
https://github.com/pcwalton/piranha

Let's get some devs to make it a first class android profiler. No
rooting or ROM's needed.

Note that some devices don't even allow to use "runas".

Mike

On Fri, Aug 26, 2011 at 8:55 AM, Mark Finkle <mark....@gmail.com> wrote:

> That might help with situations where features land and work well on
> desktop, but don't really meet expectations on mobile. Currently, we would
> file a bug to get the platform devs to try to improve the situation on
> mobile. Most of the time, the platform devs _do_ try get fixes for mobile,
> but sometimes we don't get a fix landed in a timely manner, if at all.
>
> There are improve-for-mobile bugs currently waiting for dev resources.
>
> I propose the Mobile First idea for the entire platform development team
> and not just create smaller subset teams to focus on mobile.
>

We did it for multi-process and for layer remoting and I think that was a
great success. I think we should do it for more things, but not everything.

Examples: Mats Palmgren recently implemented CSS text-overflow. Daniel
Holbert is implementing CSS flexbox. Would it make sense to do those on
mobile first? I don't think so. There's no reason to believe they'll behave
differently on mobile. Ergonomics favour developing them on desktop.

More examples: Chris Pearce reduced the thread usage of paused media
elements, Mats Palmgren refactored the way we iterate through the various
child lists of a frame. Those are sheer performance/maintainability wins on
all platforms. I don't see that there would have been any benefit developing
them on mobile first. Again, ergonomics favour developing them on desktop.

I can see that if we're making changes that have platform-specific effects,
or involve performance tradeoffs, doing mobile first or at least
concurrently makes sense. (Being serious about not taking regressions means
we often have to do mobile and desktop together.)

Two areas when we can apply this right now: we should bump the priority of
working out the fullscreen API on mobile, and Emerald (GL backend for Azure)
should be mobile-focused.

Rob
--
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]

In general I think stock feels much faster as well.

> For example, we allow you to pan and zoom as fast as the chrome will
> allow you to do it (which is damn-fast): we asynchronously get updates
> for the new regions or zoomed pixels. We *could* intentionally slow down
> scrolling so that you can't scroll as fast (so that painting is more
> visible), but in general that sounds like the wrong tradeoff.

I think if we're framing the question in terms of "which is worse,
checkerboards or slow scrolling", we've already lost. Both solutions are
really equally bad. IMHO we should shoot for daily browsing at 60 fps
with no checkerboards at all, and focus on what is preventing us from
reaching that.

Patrick

On 08/25/2011 06:27 PM, Robert O'Callahan wrote:
> On Fri, Aug 26, 2011 at 8:55 AM, Mark Finkle<mark....@gmail.com>  wrote:

>> I propose the Mobile First idea for the entire platform development team

>> and not just create smaller subset teams to focus on mobile.
>>
>
> We did it for multi-process and for layer remoting and I think that was a
> great success. I think we should do it for more things, but not everything.

Not great success. It took a hell of a long time to get parity with
desktop feature on e10s/mobile. We still don't have 100% parity.

> Examples: Mats Palmgren recently implemented CSS text-overflow. Daniel
> Holbert is implementing CSS flexbox. Would it make sense to do those on
> mobile first? I don't think so. There's no reason to believe they'll behave
> differently on mobile. Ergonomics favour developing them on desktop.

Agreed. But I wonder if profiling on mobile would have show them
hot-spots in the code that don't exist for desktop?

> More examples: Chris Pearce reduced the thread usage of paused media
> elements, Mats Palmgren refactored the way we iterate through the various
> child lists of a frame. Those are sheer performance/maintainability wins on
> all platforms. I don't see that there would have been any benefit developing
> them on mobile first. Again, ergonomics favour developing them on desktop.

We have had feedback that video is not acceptable in Fennec on Android.
My main point here is that these things are "easier" or "less
constrained" on desktop. Does the video team think the video on Fennec
is acceptable? I know Derf and others have been working hard to make
improvements.

> I can see that if we're making changes that have platform-specific effects,
> or involve performance tradeoffs, doing mobile first or at least
> concurrently makes sense. (Being serious about not taking regressions means
> we often have to do mobile and desktop together.)

Totally agree. I am being a bit over the top here only because if I'm
not, no one really takes it seriously. The status quo hasn't been giving
Mozilla the payoffs we want on mobile.

> Two areas when we can apply this right now: we should bump the priority of
> working out the fullscreen API on mobile, and Emerald (GL backend for Azure)
> should be mobile-focused.

Yes, those are great candidates.

On Fri, Aug 26, 2011 at 10:53 AM, Mark Finkle <mark....@gmail.com> wrote:

> On 08/25/2011 06:27 PM, Robert O'Callahan wrote:
>

>> Examples: Mats Palmgren recently implemented CSS text-overflow. Daniel
>> Holbert is implementing CSS flexbox. Would it make sense to do those on
>> mobile first? I don't think so. There's no reason to believe they'll
>> behave
>> differently on mobile. Ergonomics favour developing them on desktop.
>>
>
> Agreed. But I wonder if profiling on mobile would have show them hot-spots
> in the code that don't exist for desktop?

I doubt it. Anyway, we haven't really done performance work on either of
those features yet; premature optimization being evil and all that.

>  More examples: Chris Pearce reduced the thread usage of paused media
>> elements, Mats Palmgren refactored the way we iterate through the various
>> child lists of a frame. Those are sheer performance/maintainability wins
>> on
>> all platforms. I don't see that there would have been any benefit
>> developing
>> them on mobile first. Again, ergonomics favour developing them on desktop.
>>
>
> We have had feedback that video is not acceptable in Fennec on Android. My
> main point here is that these things are "easier" or "less constrained" on
> desktop. Does the video team think the video on Fennec is acceptable? I know
> Derf and others have been working hard to make improvements.

I don't think video is acceptable on Android. If we were implementing video
today, it would be a great candidate for "mobile first", but we implemented
it years ago.

Rob
--
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]

On Thu, Aug 25, 2011 at 04:06:07PM -0700, Patrick Walton wrote:
> On 8/25/11 3:17 PM, Mike Hommey wrote:
> >Note that some devices don't even allow to use "runas".
>

I doubt it, it requires privileges to switch user id. runas is
effectively a su that can't switch to root but can switch to all other
applications users.

Mike

Performance, Memory and CPU usage *are* deal-breakers:

(1) Startup Time
- actual startup time: seems to vary - based on my own experience it
is rarely under 5s, typically 5-10s. Anything slower than the stock
browser startup is not acceptable. And, perhaps, we should be even
faster:
- perceived startup time: instead of showing the "loading..." screen,
could we quickly show a cached image of the previous session while
loading browser libraries and chrome in the background? This may also
help us with WebApps going forward to give an instant native-app-like
response to users after tapping the icon.
- The startup time issue is all the more severe as Android kills
Firefox (and other apps) while running in the background very
aggressively (see (2) below). Use Firefox, switch to your Calendar for
a minute or play a round of Angry Birds, and go "back" to your
browser, and you will see a cold start of our browser.

(2) Memory Usage
- do we know by how much we can reduce actual memory usage and how
exactly that will impact the user experience?
- can we avoid getting killed in the background by Android any other
way? e.g. by offering a browser widget which could basically be an
awesome bar-like search box which could keep some of our libraries in
memory?

(3) Page switching / rendering
- Tap on a link on a page, we start showing the next page as soon as
we get the first bytes from the CSS or page - on slower connections
you see either checkerboard or white for a while until the page gets
loaded. That is a very "honest" way of showing that target page,
because we show what we get, as soon as we get it. However, it makes
us appear slow!
- Most mobile browsers *seem* to switch to the next page only once the
page is rendered. Overall, we may be faster, but other browsers seem
much faster, as they switch over to the full page while Firefox users
can sometimes watch the page to get rendered. *If* this observation is
true, could we consider switching to the next page once there to be
seen?

(4) panning / zooming / readability:
- We still checkerboard a lot while loading pages or zooming: e.g.
zoom in to NYT.com - zoom out again - see checkerboard while you zoom
-  panning is not as smooth as in the stock browser - our panning can
be laggy, jerky at times: pan up and down quickly to see how the web
page follows your movement with a visible delay and "jumps" - try the
same with the stock browser
- the readability project should take care of the performance issues
related to double-tap-to-zoom and reflow, I assume?

(5) JS and page load
- For JavaScript performance: Kraken makes us look really good,
SunSpider shows us just barely faster than the Android stock browser
on Honeycomb, and V8 actually shows that we are slower. What would be
a measurable goal for us? Can we boost mobile JS performance
significantly? And what would be the user impact and visual advantage
on your average web page?
- Page load: QA did some tests to measure page load times of Fx4
compared to other browsers: the results were mixed, there was no clear
winner: we were faster than other browsers on a few pages, but on most
pages, stock or other mobile browsers were as fast or faster, in some
cases significantly faster. We may run those numbers again under
controlled conditions

(6) Add-ons and Input Methods
- I wonder how add-ons and Swiftkey, Swype, etc. hurt our performance?

(7) Measuring and Optimizing Performance
- Is the data we get from users today enough to find Performance
issues? Or do we need more than beta tools and zippity?
- Can we publish concrete guidance for users on how to make their
mobile Firefox experience faster?

To revolutionize the (mobile) web, we need to set new standards for
fastest performance and best ease-of-use to stand out from the crowd
and to lead innovation. What matters most to mobile users is a
seamless and pleasant online experience across their devices. Being
perceived as too slow significantly limits our reach today. We need
all your ideas and support to get this fixed as soon as possible.
Thanks for sharing your ideas.

On Aug 24, 10:13 am, Michael Verdi <mve...@mozilla.com> wrote:
> Mike Hommey wrote:
> > There is absolutely no way we can get as fast as the "native" browser
>
> We've got a big problem then. Even the people who love Firefox complain
> that it's too slow.https://market.android.com/details?id=org.mozilla.firefoxhttps://input.mozilla.com/en-US/?q=slow&product=mobile&version=--&sen...
>
> - Michael

On Fri, Aug 26, 2011 at 3:19 PM, Thomas Arend <tarend...@gmail.com> wrote:
> - do we know by how much we can reduce actual memory usage and how
> exactly that will impact the user experience?

I think that using ashmem for discardable memory (JIT code, maybe;
image cache; off-screen tabs if we don't already discard; thumbnails;
memory cache) would let us reduce our effective memory footprint under
pressure a fair bit.  I think dougt is looking into this, and I'm
pretty sure it's what the Android browser and other system apps do.

> - can we avoid getting killed in the background by Android any other
> way? e.g. by offering a browser widget which could basically be an
> awesome bar-like search box which could keep some of our libraries in
> memory?

I think that'd be more likely to get both of them killed, but it also
seems sort of user-hostile.  Maybe I'm over-reacting, though.

Mike

On 08/26/2011 03:19 PM, Thomas Arend wrote:

> (1) Startup Time
> - actual startup time: seems to vary - based on my own experience it
> is rarely under 5s, typically 5-10s. Anything slower than the stock
> browser startup is not acceptable. And, perhaps, we should be even
> faster:
> - perceived startup time: instead of showing the "loading..." screen,
> could we quickly show a cached image of the previous session while
> loading browser libraries and chrome in the background? This may also
> help us with WebApps going forward to give an instant native-app-like
> response to users after tapping the icon.

Some current bugs for improving startup:
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=sw%3Amobilestartupshrink

> - The startup time issue is all the more severe as Android kills
> Firefox (and other apps) while running in the background very
> aggressively (see (2) below). Use Firefox, switch to your Calendar for
> a minute or play a round of Angry Birds, and go "back" to your
> browser, and you will see a cold start of our browser.

This is more memory related, and less startup

> (2) Memory Usage
> - do we know by how much we can reduce actual memory usage and how
> exactly that will impact the user experience?
> - can we avoid getting killed in the background by Android any other
> way? e.g. by offering a browser widget which could basically be an
> awesome bar-like search box which could keep some of our libraries in
> memory?

Killing the child process is another drastic way to reduce the memory
footprint

> (4) panning / zooming / readability:
> - We still checkerboard a lot while loading pages or zooming: e.g.
> zoom in to NYT.com - zoom out again - see checkerboard while you zoom
> -  panning is not as smooth as in the stock browser - our panning can
> be laggy, jerky at times: pan up and down quickly to see how the web
> page follows your movement with a visible delay and "jumps" - try the
> same with the stock browser
> - the readability project should take care of the performance issues
> related to double-tap-to-zoom and reflow, I assume?

You are referring to:
https://bugzilla.mozilla.org/show_bug.cgi?id=627842

I don't know if this affects reflow-on-zoom behavior. It is more about
pure readability.

> - Page load: QA did some tests to measure page load times of Fx4
> compared to other browsers: the results were mixed, there was no clear
> winner: we were faster than other browsers on a few pages, but on most
> pages, stock or other mobile browsers were as fast or faster, in some
> cases significantly faster. We may run those numbers again under
> controlled conditions

> (6) Add-ons and Input Methods
> - I wonder how add-ons and Swiftkey, Swype, etc. hurt our performance?

* Regarding add-ons, what's true for desktop is true for mobile: add-ons
_can_ slow down the app.
* Keyboards/IMEs have been a pain on mobile, but I don't think
performance is the main issue. I could be wrong.

> (7) Measuring and Optimizing Performance
> - Is the data we get from users today enough to find Performance
> issues? Or do we need more than beta tools and zippity?
> - Can we publish concrete guidance for users on how to make their
> mobile Firefox experience faster?

We need better tools for measuring code speed. Talos, Telemetry and
Zippity are good for a certain class of data, but we need more
fine-grained tools as well.

Some possible examples include:
* https://wiki.mozilla.org/Using_SlowCalls
* https://github.com/pcwalton/piranha

There is a bug filed to create nightly builds that are "slow-call"
enabled, which would make it easier for people to get some JS profile data:
https://bugzilla.mozilla.org/show_bug.cgi?id=592518

On 08/26/2011 03:52 PM, Mark Finkle wrote:
> On 08/26/2011 03:19 PM, Thomas Arend wrote:
>
>> (1) Startup Time
>> - actual startup time: seems to vary - based on my own experience it
>> is rarely under 5s, typically 5-10s. Anything slower than the stock
>> browser startup is not acceptable. And, perhaps, we should be even
>> faster:
>> - perceived startup time: instead of showing the "loading..." screen,
>> could we quickly show a cached image of the previous session while
>> loading browser libraries and chrome in the background? This may also
>> help us with WebApps going forward to give an instant native-app-like
>> response to users after tapping the icon.
>
> Some current bugs for improving startup:
> https://bugzilla.mozilla.org/buglist.cgi?quicksearch=sw%3Amobilestartupshrink

See also:

* Bug 663762 - Splash screen could offer more information to the user
(caching the last screenshot)
* Bug 675051 - Load minimal amount of UI at startup

Thomas Arend wrote:
> Performance, Memory and CPU usage *are* deal-breakers:
> (1) Startup Time

Mark Finkle wrote:
> See also:
>
> * Bug 663762 - Splash screen could offer more information to the user
> (caching the last screenshot)
> * Bug 675051 - Load minimal amount of UI at startup

I hope we can do something. The current situation makes me groan when I
see the Firefox logo. That makes me sad.

- Michael

> Ergonomics favour developing them on desktop.

Hey Roc,

I think this is correct.  If you can design and develop and debug on the desktop, that is great.  What I don't want to see is mobile as an afterthought.  The people you mentioned should be testing along the way to ensure that what they are building will work great on mobile.

Doug

It's easy to set that goal for a kernel. It only has itself to blame for
startup speed. We actually have to fight kernel, linker, android
userspace, etc. A lot less room for aggressive improvements. We can't
realistically aim for < 1.5s given the environment we are running it.

For comparison, on maemo we couldn't aim < 3s.

Taras

Actually telemetry reports amount of ram and number of cpu cores. We do
not yet report cpuid

Taras

On 08/25/2011 01:10 PM, Mark Finkle wrote:

Actually telemetry reports amount of ram and number of cpu cores. We do

not yet report cpuid

Taras

I think low-level platform performance work is easier to measure on
mobile the cost of memcpy, context-switches, IO, etc is higher. I
suspect the same might apply to optimizing how/when we repaint stuff.

I suspect JS people might find some perf tradeoff decisions easier to
make due to perf differences being bigger on mobile. Stuff likes
deciding on when to discard memory should be a lot more obvious on mobile.

The recent big wins in performance-team department all came out of "does
it help mobile" mindset: omnijar, startupcache, elfhack, fat libxul.so,
etc.

The next set of GCC(PGO-guided ordering, etc) improvements are also
being targeted at mobile too.

Taras

> For comparison, on maemo we couldn't aim < 3s.

To be fair, the reason for that was not maemo itself but the hardware of
the N900 with a 600MHz CPU and 256MB of RAM.
I'm pretty sure on an Android phone with those constraints, <3s would
also be unrealistic - if we run at all.

Robert Kaiser

--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community should think about. And most of the
time, I even appreciate irony and fun! :)

On 2011-08-31 5:51 PM, Taras Glek wrote:
> It's easy to set that goal for a kernel. It only has itself to blame for
> startup speed. We actually have to fight kernel, linker, android
> userspace, etc. A lot less room for aggressive improvements. We can't
> realistically aim for < 1.5s given the environment we are running it.

The goal was not just for the kernel; it was to boot to desktop, with
all I/O done, disk idle, computer ready to go. They made kernel changes
as part of that project, but that was only part of the story.

I urge you to read the LWN story[1] if you haven't; it's very
enlightening and has changed my outlook on how to make systems fast.

Joe

1. https://lwn.net/Articles/299483/

On Thu, Sep 01, 2011 at 04:14:59PM -0400, Joe Drew wrote:
>
> On 2011-08-31 5:51 PM, Taras Glek wrote:
> >It's easy to set that goal for a kernel. It only has itself to blame for
> >startup speed. We actually have to fight kernel, linker, android
> >userspace, etc. A lot less room for aggressive improvements. We can't
> >realistically aim for < 1.5s given the environment we are running it.
>
> The goal was not just for the kernel; it was to boot to desktop,
> with all I/O done, disk idle, computer ready to go. They made kernel
> changes as part of that project, but that was only part of the
> story.

The point is: unless you change the kernel, the linker and android
userspace, you can't set incredible goals. That's hard to do on consumer
phones.

Mike

What size is your tablet? I think the failure to rewrap text blocks to
screen width when zooming is *the* major problem in Firefox for
Android (on fast phones like Galaxy S II it is worse that any perf
issue). See the true story in
https://bugzilla.mozilla.org/show_bug.cgi?id=684570 . However, the
same friend for whom (apparent) lack of rewrap on zoom was a
deal-breaker on Galaxy S II is OK with not having the feature on a 10"
Android tablet. I haven't tried a 10" Android tablet, but for me it
was a deal-breaker still on a 7" tablet when I considered buying the
original Galaxy Tab last year.

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

On Sunday 2011-09-04 14:06 +0300, Henri Sivonen wrote:
> What size is your tablet? I think the failure to rewrap text blocks to
> screen width when zooming is *the* major problem in Firefox for
> Android (on fast phones like Galaxy S II it is worse that any perf
> issue). See the true story in
> https://bugzilla.mozilla.org/show_bug.cgi?id=684570 . However, the
> same friend for whom (apparent) lack of rewrap on zoom was a
> deal-breaker on Galaxy S II is OK with not having the feature on a 10"
> Android tablet. I haven't tried a 10" Android tablet, but for me it
> was a deal-breaker still on a 7" tablet when I considered buying the
> original Galaxy Tab last year.

I think it's even better to have font sizes inflated to begin with,
so that there doesn't need to be reflow on zoom (with the weird
modality that introduces, and the weird distinction between zooming
with multitouch and the less-discoverable zooming with double-tap).
I'm working on that in
https://bugzilla.mozilla.org/show_bug.cgi?id=627842

-David

--
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla Corporation               http://www.mozilla.com/   𝄂

On Sun, Sep 4, 2011 at 5:39 PM, L. David Baron <dba...@dbaron.org> wrote:
> I think it's even better to have font sizes inflated to begin with,
> so that there doesn't need to be reflow on zoom

This risks breaking desktop-oriented layouts while the HTC/Opera
solution doesn't.

> (with the weird modality that introduces,

What weird modality do you mean? In the HTC flavor of the stock
browser and in Opera Mobile, the rewrapping works great. What's weird
about it? Do you mean weird from the user point of view or weird from
the CSS point of view?

> and the weird distinction between zooming
> with multitouch and the less-discoverable zooming with double-tap).

I think having a distinction is a bug in Fennec. AFAICT, there's no
distinction between double-tap and pinch zooming as far as how
rewrapping behaves at a given zoom level in the HTC flavor of the
stock browser or in Opera Mobile, which is, IMO, how it should be.

> I'm working on that in
> https://bugzilla.mozilla.org/show_bug.cgi?id=627842

Is there a reason why this this solution would be better than the
HTC/Opera solution (other than not having to reflow inline content
when zooming)?

Are there any plans to implement the behavior that Opera Mobile has?
(At any zoom level, no matter how the user arrives at the zoom level,
the inline content in a block wraps as if the inner width of the block
didn't exceed the width of the screen but the outer dimensions of the
block--including the border dimensions--don't change.)

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

On Sunday 2011-09-04 20:05 +0300, Henri Sivonen wrote:
> On Sun, Sep 4, 2011 at 5:39 PM, L. David Baron <dba...@dbaron.org> wrote:
> > I think it's even better to have font sizes inflated to begin with,
> > so that there doesn't need to be reflow on zoom
>
> This risks breaking desktop-oriented layouts while the HTC/Opera
> solution doesn't.

It seems to work pretty well on iOS.

> > (with the weird modality that introduces,
>
> What weird modality do you mean? In the HTC flavor of the stock
> browser and in Opera Mobile, the rewrapping works great. What's weird
> about it? Do you mean weird from the user point of view or weird from
> the CSS point of view?

I mean from a user point of view:  that there's one set of zooming
commands (double-tap) that cause rewrapping and one set (multitouch)
that don't.  This is particularly weird for users who do
predominantly multitouch, and need to learn (1) that if they want to
zoom on text they need to not use multitouch and (2) once they do
that, they also can't zoom back out using multitouch.

> > and the weird distinction between zooming
> > with multitouch and the less-discoverable zooming with double-tap).
>
> I think having a distinction is a bug in Fennec. AFAICT, there's no

It's the same in the stock Android browser.

> distinction between double-tap and pinch zooming as far as how
> rewrapping behaves at a given zoom level in the HTC flavor of the
> stock browser or in Opera Mobile, which is, IMO, how it should be.

I'd be interested to experiment with such a UI; I've never had a
chance to.  It's really not clear to me what panning should do once
you're zoomed like that.  Does the panning UI ignore the rewrapping
behavior entirely (and always position the content at the
start-edge), or does it do something more clever?  Either way, I
think it breaks the simple mental model of multitouch zoom + pan.

> Is there a reason why this this solution would be better than the
> HTC/Opera solution (other than not having to reflow inline content
> when zooming)?

I think it's a much simpler mental model for users; it doesn't break
the multitouch zoom+pan model at all.

-David

--
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla Corporation               http://www.mozilla.com/   𝄂

On Sun, Sep 4, 2011 at 8:17 PM, L. David Baron <dba...@dbaron.org> wrote:
> On Sunday 2011-09-04 20:05 +0300, Henri Sivonen wrote:
>> On Sun, Sep 4, 2011 at 5:39 PM, L. David Baron <dba...@dbaron.org> wrote:
>> > I think it's even better to have font sizes inflated to begin with,
>> > so that there doesn't need to be reflow on zoom
>>
>> This risks breaking desktop-oriented layouts while the HTC/Opera
>> solution doesn't.
>
> It seems to work pretty well on iOS.

I disagree. I think what Opera Mobile does is vastly superior to what
Mobile Safari does. (I'm actually rather surprised that users who
haven't tried anything better consider Mobile Safari good enough on
this front.)

>> > (with the weird modality that introduces,
>>
>> What weird modality do you mean? In the HTC flavor of the stock
>> browser and in Opera Mobile, the rewrapping works great. What's weird
>> about it? Do you mean weird from the user point of view or weird from
>> the CSS point of view?
>
> I mean from a user point of view:  that there's one set of zooming
> commands (double-tap) that cause rewrapping and one set (multitouch)
> that don't.  This is particularly weird for users who do
> predominantly multitouch, and need to learn (1) that if they want to
> zoom on text they need to not use multitouch and (2) once they do
> that, they also can't zoom back out using multitouch.

A distinction between the zooming gestures isn't an inherent
characteristic of rewrapping on zoom. Opera Mobile doesn't have such a
distinction.

>> > and the weird distinction between zooming
>> > with multitouch and the less-discoverable zooming with double-tap).
>>
>> I think having a distinction is a bug in Fennec. AFAICT, there's no
>
> It's the same in the stock Android browser.

OK. It's been a while since I've experimented with this in the HTC
flavor of the stock browser.

>> distinction between double-tap and pinch zooming as far as how
>> rewrapping behaves at a given zoom level in the HTC flavor of the
>> stock browser or in Opera Mobile, which is, IMO, how it should be.
>
> I'd be interested to experiment with such a UI; I've never had a
> chance to.  It's really not clear to me what panning should do once
> you're zoomed like that.  Does the panning UI ignore the rewrapping
> behavior entirely (and always position the content at the
> start-edge), or does it do something more clever?  Either way, I
> think it breaks the simple mental model of multitouch zoom + pan.

In Opera Mobile, panning doesn't affect wrapping. So if you've zoomed
so much that the width of the screen is narrower than the width (as in
between paddings) of the block, the lines in the block wrap so that
the text occupies the left side of the block box (at least for LTR
text) and the right side of the block box just shows the background.
So if you pan to see stuff on the right, you first have to pan over
the empty space in the block box, since rewrapping doesn't change the
width of any block box.

Since the wrapping happens on a per block-box basis in Opera, when you
encounter a block box whose right edge of the left padding is not
aligned with the right edge of the left padding of the box above it,
you may have to pan sideways a little. For example, if you have a list
item or a blockquote, the width at which text wraps in the list items
or blockquotes is the same as in paragraphs, but the text in list
items and blockquotes starts more to the right, so you have to pan a
bit to recenter on the list item or blockquote. (Aside: When the same
situation occurs in non-touch Opera Mini, Opera Mini helpfully does
the recentering on behalf of the users.)

So the effect on panning isn't ideal, but I think the effect on
zooming is *vastly* superior to whatever Mobile Safari does or what
Firefox does by default or what the Samsung flavor of the Android
browser does.

>> Is there a reason why this this solution would be better than the
>> HTC/Opera solution (other than not having to reflow inline content
>> when zooming)?
>
> I think it's a much simpler mental model for users; it doesn't break
> the multitouch zoom+pan model at all.

If the text size that the solution chooses is still too small when the
line length matches the screen width, what recourse does the user
have? With Opera Mobile, the user can choose any zoom level and the
line length adjusts so that any given block can be read without
horizontal panning.

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

On Sunday 2011-09-04 20:44 +0300, Henri Sivonen wrote:
> If the text size that the solution chooses is still too small when the
> line length matches the screen width, what recourse does the user
> have? With Opera Mobile, the user can choose any zoom level and the
> line length adjusts so that any given block can be read without
> horizontal panning.

Yeah, I agree that that's a problem; it's hard to offer a solution
in the font size inflation model other than a preference for the
"minimum readable text size".

I think combining the zoom-method-independent rewrapping that you
describe with font size inflation may be a best-of-both-worlds
solution.

-David

--
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla Corporation               http://www.mozilla.com/   𝄂

On 09/04/2011 10:17 AM, L. David Baron wrote:
> On Sunday 2011-09-04 20:05 +0300, Henri Sivonen wrote:
>> On Sun, Sep 4, 2011 at 5:39 PM, L. David Baron<dba...@dbaron.org>  wrote:
>>> I think it's even better to have font sizes inflated to begin with,
>>> so that there doesn't need to be reflow on zoom
>>
>> This risks breaking desktop-oriented layouts while the HTC/Opera
>> solution doesn't.
>
> It seems to work pretty well on iOS.

iOS also has a "-webkit-text-size-adjust" that authors can use to
prevent text scaling if it breaks their layouts.  To prevent broken
pages in Fennec, we might need to implement a similar property, *and* we
would need authors to actually use it.

> I'd be interested to experiment with such a UI; I've never had a
> chance to.  It's really not clear to me what panning should do once
> you're zoomed like that.

I agree with Henri that Opera Mobile 11 for Android solves these
problems really well, and I prefer it to the iOS Safari approach.

>
> I've been thinking a bit about what can do, and what we need to do, for
> Firefox performance on mobile devices.

I'm late to the party here.  I want to make a suggestion relating to memory
usage:  to really get mobile memory usage down, we need a clear target.

I wrote about memory targets on the MemShrink wiki page
(https://wiki.mozilla.org/Performance/MemShrink#areweslimyet.com), and
compared the situation to JS performance and arewefastyet.com (a.k.a AWFY):

> Why was AWFY so successful? Some key characteristics.
>
> - The benchmarks were easy to choose: everybody already used SS and V8, and
>   then Mozilla released Kraken. They run quickly, too, which is nice for
>   devs, and allows expensive tools (like Cachegrind) to be used.
>
> - The metrics were easy to choose. SS time, V8 time, Kraken time. They can be
>   measured easily, precisely, and fairly repeatably. You can break the total
>   time down into per-benchmark times, which really helps with understanding
>   improvements and regressions. They're easy for devs to run on their own
>   machine.
>
> - Understanding where the time went was fairly easy, because there are good
>   time-oriented profilers: Shark, Cachegrind, etc.
>
> - There was a well-defined goal: match or beat the other browsers.
>
> In comparison, for AWSY there is no good and/or standard benchmark suite;
> metrics are less clear and/or harder to measure; the memory profiling tools
> aren't as good; but most importantly, there's no well-defined goal w.r.t. any
> benchmarks.

This is all very cautious.  It's time to be bolder.

- W.r.t. profilers:  about:memory is much better now, which really helps, and
  it will continue to do so -- we have 16 open bugs for additional memory
  reporters, and 13 of them are assigned, so we should make great progress in
  the next few weeks.  (But this point relates only minimally to the question
  of a hard target, so I'll move on.)

- W.r.t. metrics:  let's just choose RSS.  It measures physical memory usage,
  and you can't get much central than that.  Equally importantly, it's
  reported (via about:memory) from /proc/<pid>/maps which comes from the
  kernel, so it's as trustworthy as anything.  (In comparison, the Android
  task manager seems to give funny numbers, I think this might be because it
  measures "Uss" (http://elinux.org/Android_Memory_Usage) which will
  under-report for us due to our two process architecture.)

- W.r.t. benchmarks:  let's just pick some important sites.  gmail.com,
  facebook.com.  Something popular.

- W.r.t. goals:  if we can base this on a particular device or devices (e.g.
  phone X has 512MB of memory, let's target that) then well and good.  Failing
  that, let's just pick something arbitrary, like 2x less memory than what we
  currently use.

In other words, let's just set a goal like "get total RSS for the two processes
when opening sites A, B, and C below X MB".  Then we can track it like we did
with AWFY.  You can say "well, maybe that's not the best thing to measure, blah
blah" to which I say "yeah, Sunspider and V8 are pretty crappy measures of JS
performance but AWFY still helped our general JS performance hugely".

Having a fixed target, even a flawed one, gets everyone's attention.  You make
what you measure.  Without a clear target we're less likely to make progress.

Nick

One could use a snapshot of a wikipedia article, or perhaps a fixed
version of etherpad (and page content). One could even use a fixed
version of zimbra (with fixed content).

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

--
Sent from my mobile device

On Wed, Sep 7, 2011 at 5:41 PM, timeless <time...@gmail.com> wrote:
> Gmail/facebook are problematic because neither their content nor their
> site design is stable.
>
> One could use a snapshot of a wikipedia article, or perhaps a fixed
> version of etherpad (and page content). One could even use a fixed
> version of zimbra (with fixed content).

Sure, and people will probably quibble with my other suggestions.
That's fine and good!  But the basic idea (pick a reasonable, specific
target and push hard towards it) is unchanged.

Nick

On Sun, 2011-09-04 at 11:07 -0700, L. David Baron wrote:
> On Sunday 2011-09-04 20:44 +0300, Henri Sivonen wrote:
> > If the text size that the solution chooses is still too small when the
> > line length matches the screen width, what recourse does the user
> > have? With Opera Mobile, the user can choose any zoom level and the
> > line length adjusts so that any given block can be read without
> > horizontal panning.
>
> Yeah, I agree that that's a problem; it's hard to offer a solution
> in the font size inflation model other than a preference for the
> "minimum readable text size".
>
> I think combining the zoom-method-independent rewrapping that you
> describe with font size inflation may be a best-of-both-worlds
> solution.

On Tue, Sep 6, 2011 at 11:49 PM, Nicholas Nethercote
<n.neth...@gmail.com> wrote:
>
> - W.r.t. metrics:  let's just choose RSS.  It measures physical memory usage,
>  and you can't get much central than that.  Equally importantly, it's
>  reported (via about:memory) from /proc/<pid>/maps which comes from the
>  kernel, so it's as trustworthy as anything.

I was doing some thinking about this.  A typical thing people do is
start up the browser, load a page or two, then measure memory usage.
Let's call this the "stable" memory usage.  They'll often use
about:memory or a task manager to do this.

Unfortunately, stable usage can be substantially lower than peak
usage.  I just tried loading Gmail and TechCrunch in a Linux64 desktop
dev build;  stable RSS was 284MB, but peak RSS was 341MB, which is
1.2x higher.

Which is more important?  I've heard that on some devices Fennec is
killed as soon as it starts paging.  If that's true, then peak is
certainly important.

Unfortunately, peak isn't easy to measure.  You can get peak RSS from
/proc/<pid>/status on Linux (and Android?), it's the "VmHWM" field.
(And current RSS is the "VmRSS" field.)  That's how I got my numbers
above.  And you can get peak vsize similarly ("VmPeak" and "VmSize").

But global numbers like RSS and vsize only get us so far.  All the
detailed measurements in about:memory are stable measurements, not
peak.  The only way I know of to get detailed peak measurements is
with Massif.  Unfortunately, Massif is a pain to use.

I know of three things that can cause short-lived memory spikes:

- The cycle collector.  I've seen this take over 20MB before.

- JSParseNode.  I've seen this take as much as 70MB before, and
https://bugzilla.mozilla.org/show_bug.cgi?id=626932 is open about it.
(We made this a MemShrink:P3 bug because the usage is very short-lived
but now I wonder if we should reconsider that.  Happily, Brendan is
looking at it.)

- Type inference has some temporary analysis data that is cleared on
each GC.  It's long-lived enough that it shows up on about:memory
under "analysis-temporary".

The first two of these I know about because they show up a lot in
Massif profiles (e.g.
http://blog.mozilla.com/nnethercote/2010/12/09/memory-profiling-firefox-with-massif/).

I'm not sure what to do about this right now, but I thought it worth
mentioning.  The "dark matter" of the "heap-unclassified" entry in
about:memory has received a lot of attention because it's obvious.
This difference between peak and stable usage is another kind of dark
matter that's much less obvious but might be as important.

Nick

On 9/8/11 10:11 PM, Nicholas Nethercote wrote:
> I know of three things that can cause short-lived memory spikes:

Some other things that I think can do it:

1)  Frame construction (creation of all the frame construction items
before we create frames for them).  The good news is that most pages
have few enough elements that this has a hard time going over a few MB.

2)  Painting (display lists).

3)  Rulehash construction (has some temporary data structures that are
O(N) in size in number of CSS selectors used on the page; again, this is
usually not that bad because pages have at most ~20k selectors and the
temp data is < 32 bytes per selector, I'm pretty sure).

4)  Ruletree growth when dynamic changes are happening before ruletree
GC happens.

5)  Script and stylesheet parsing: for a bit the source and the parsed
representation are both in memory at once.  The spike size is the size
of the script or stylesheet text, so probably a few hundred KB on pages
where there are significant scripts/stylesheets.

I suspect these are all much smaller allocations than the ones you
mention, though.

-Boris

----- Original Message -----
> I know of three things that can cause short-lived memory spikes:
>

> - The cycle collector. I've seen this take over 20MB before.

> - W.r.t. benchmarks:  let's just pick some important sites.  gmail.com,
>   facebook.com.  Something popular.

> - W.r.t. goals:  if we can base this on a particular device or devices (e.g.
>   phone X has 512MB of memory, let's target that) then well and good.  Failing
>   that, let's just pick something arbitrary, like 2x less memory than what we
>   currently use.
>
> In other words, let's just set a goal like "get total RSS for the two processes
> when opening sites A, B, and C below X MB".  Then we can track it like we did
> with AWFY.  You can say "well, maybe that's not the best thing to measure, blah
> blah" to which I say "yeah, Sunspider and V8 are pretty crappy measures of JS
> performance but AWFY still helped our general JS performance hugely".
>
> Having a fixed target, even a flawed one, gets everyone's attention.  You make
> what you measure.  Without a clear target we're less likely to make progress.