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

On 8/22/2011 9:18 PM, David Mandelin wrote:
>
> A3. Memory Usage: Unknown, probably bad.
>
>
>
> Getting better information here (higher quality data and/or better
> understanding of it) should be a high priority.
>
> For now, based on what information we do have, memory usage on Android
> seems pretty bad. Some indirect evidence: I get a lot of crashes, which
> I think might be OOMs. Also, my phone has 1 GB RAM while Taras's has 512
> MB, and I seem to get better perceived performance, which points to
> memory limits. (Taras says other apps, including the music player, get
> tossed out of RAM when he uses Firefox.) Finally, comments in the App
> Store suggest that on wimpy devices, Firefox is much slower than other
> browsers, which appears not to be the case on powerful devices.
>
> Looking at the direct measurements, both Taras and I think that ~80 MB
> for the chrome part of the browser is unacceptable. Taras says he thinks
> 20 MB (of which 10 MB is for JVM) would be a good target. He also says
> that XUL seems to be responsible for about half the memory we do use.
I absolutely think that we need to better understand the memory usage of 
the content process as well as the chrome process.
>
>
> Taras also said that Alon Zakai told him IPC overhead between main and
> content processes is hurting us here.
I keep hearing this anecdotally but have never had anyone actually give 
us numbers that we could optimize against. There's lots of opportunity 
to measure and refine message passing overhead, but in contrived tests 
its so fast that you should normally even notice it's there.

>
>
> A6. Panning/Zooming: Bad/OK.
>
> I get lots of checkerboarding if I pan quickly, moreso than in other
> mobile browsers. Zooming is OK for me, but I do see complaints about it
> in the app store, and the graphics quality during zooming is lower than
> stock, so maybe we are using that to compensate for lower underlying
> performance.
There are tradeoffs that could be made here, but this surprises me 
greatly. I generally feel that Firefox is just so stupendously better at 
panning/zooming than stock...

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

We should definitely look at making the checkerboard less visible (using 
the page background color etc), but I was pretty sure that this was 
something where we were winning hands-down, and I'd really like to 
understand the opposite viewpoint better.
> C2. Single-Process Architecture.
>
> We apparently have evidence that IPC is slowing us down. I don't have
> any measurements there, so I don't know much about the problem. But
> again, we need to think hard about whether the current multiprocess
> architecture is going to get us to where we want to be (taking into
> account any predicted improvements in Android IPC) and if it won't, it's
> time to do something about that.
We'd have to measure really carefully: the basic trade in multi-process is:

* resilience from content misbehaving or large pages causing UI lag
* much better UI responsiveness when panning/zooming (although 
apparently the perception is mixed here!)
* increased memory usage
* IPC overhead (?)

I don't think we can possible make this call until we understand the 
magnitude of the memory/IPC overhead

--BDS