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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Benjamin Smedberg
On 8/22/2011 9:18 PM, David Mandelin wrote:

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

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

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

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

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

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

--BDS

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

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

Ehsan Akhgari
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
_______________________________________________
dev-performance mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-performance