812441 - Potential optimizations to HTML parsing/loading for local apps

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Performance, defect, P3)

Description

[Zibi Braniecki [:zbraniecki][:gandalf]]

The numbers coming from performance.timing API show a major difference in the performance of DOM loading for webapps vs. local apps. on Unagi phone.

NAME                                     emulator+loc  Unagi+web  Unagi+loc
performance.navigationStart              0               0          0
(…)
performance.responseEnd                  0               1          121
performance.domLoading                   1               221        469
performance.domInteractive               16              334        983
performance.domContentLoadedEventStart   25              332        1181
performance.domContentLoadedEventEnd     25              333        1181
performance.domComplete                  25              366        1189
performance.loadEventStart               25              366        1189

NAME                                     UnaNoOOP+web       UnaNoOOP+local  
performance.navigationStart              0                  0               
(…)              
performance.responseEnd                  0                  11              
performance.domLoading                   229                383              
performance.domInteractive               285                809              
performance.domContentLoadedEventStart   366                1182              
performance.domContentLoadedEventEnd     366                1182            
performance.domComplete                  400                1182              
performance.loadEventStart               400                1182              

The visible difference is between responseEnd and domLoading and another between domLoading and domInteractive.

Comment 1

[Zibi Braniecki [:zbraniecki][:gandalf]]

Steps to reproduce:

 - take the source of the file from URL and place it instead of any local app index.html (or add another local app)
 - reboot Unagi
 - open Gaia browser and navigate to URL
 - open the custom app

In order to gather numbers for the cold boot reboot the phone between repeating the query.

Comment 2

[Zibi Braniecki [:zbraniecki][:gandalf]]

More data. I decided to try to move the test outside of Settings app into it's own little perfapp. This resulted in speedups in dom loading!

NAME                            desktop Unagi+Settings  Unagi+perftest
p.t.navigationStart:            0       0               0
p.t.responseEnd:                24      44              10
p.t.domLoading:                 30      501             139
p.t.domInteractive:             43      978             273
p.t.domContentLoadedEventStart: 44      993             283
p.t.domContentLoadedEventEnd:   45      993             283
p.t.domComplete:                46      1016            301
p.t.loadEventStart:             46      1016            301

My only ideas was that maybe application.zip size impacts this, so I removed everything from settings application.zip shrinking it from 700kb to 11kb. No difference.

In my perftest app I'm getting stable result with no variance, in Settings the variance on domLoading and domInteractive is ~10, but this is an average from 5 cold loads.

The numbers for the same code loaded from the web on Gaia::Browser are similar to PerfTest, so that's probably how far we can get with current DOM engine.

This branches into two questions:
1) Why is Settings app that much slower?
2) Are there any low hanging fruits to lower the DOM cost for the webapp on Unagi?

Comment 3

[Zibi Braniecki [:zbraniecki][:gandalf]]

we can ignore the Settings app. It's bug 808919 - Settings app is loaded during boot.

So, the core of the bug is: DOM loading takes ~300ms on Unagi. Can we reduce this number?

Comment 4

[Zibi Braniecki [:zbraniecki][:gandalf]]

I measured difference between loading almost empty HTML file and full settings app HTML (uncommented all sections):

NAME                            min HTML        long HTML
p.t.navigationStart:            0               0
p.t.responseEnd:                10              11
p.t.domLoading:                 139             157
p.t.domInteractive:             273             547
p.t.domContentLoadedEventStart: 283             664
p.t.domContentLoadedEventEnd:   283             664
p.t.domComplete:                301             664
p.t.loadEventStart:             301             664

The current dirty hack to comment out all sections and then innerHTML one by one when requested saves another ~300ms.

Is there a way to shave it?

Comment 5

[Zibi Braniecki [:zbraniecki][:gandalf]]

We now have a case where we need to load big HTML file but we show just a small portion of it at the time - Gaia's Settings app ( https://github.com/mozilla-b2g/gaia/blob/master/apps/settings/index.html ).

The way we avoid paying for it right now is by commenting out everything and loading by injecting comment's content via innerHTML into it's block.

That's hardly the good example for how to write webapps.

Henri: would it be possible to lazy load hidden HTML blocks?

Comment 6

[Henri Sivonen (:hsivonen)]

(In reply to Zbigniew Braniecki [:gandalf] from comment #5)
> The way we avoid paying for it right now is by commenting out everything and
> loading by injecting comment's content via innerHTML into it's block.

(In theory, you are supposed to use <script type="non-js/type">...</script> for that, not comments, where "non-js/type" is something that is not a known JS, VBScript or Dart MIME type and unlikely to be a MIME type of a future scripting language [as unlikely as it is that we'd ever support a non-JS scripting language].)

> Henri: would it be possible to lazy load hidden HTML blocks?

The hiddenness couldn't depend on CSS. It would have to depend on markup. And if it depended on markup, the parser would still have to parse the block somehow to see where it ends.

The closest thing coming up in the feature pipeline is the Chrome-proposed <template> element, but it involves creating as many DOM nodes as there are start tags at the time of the initial document parse. Thus, if early node creation is your bottleneck, <template> won't help you.

So, no.

Comment 7

[Hubert Figuiere [:hub]]

Does this still occur on 1.3 or 1.4 on current hardware? (unagi is deprecated)

Comment 8

[Geo Mealer [:geo] -- This account is inactive after 2015-07-07]

Refreshing the needinfo for comment 7

Comment 9

[Zibi Braniecki [:zbraniecki][:gandalf]]

removing NI from old bugs.

Comment 10

[Zibi Braniecki [:zbraniecki][:gandalf]]

I should not be allowed near computers...

Comment 11

[BMO Automation]

Firefox OS is not being worked on