951052 - Improve performance on hixie's element insertion microbenchmark on Android

Status: NEW

(Core :: DOM: Core & HTML, defect)

Description

[Salar]

DOM operations are very slow in android platform.

Here are some test results according to Hixie's performance test:
http://nontroppo.org/timer/Hixie_DOM.html

Tested on HTC Desire C with Cpu Snapdragon 600MH
Android version 4.0.3

Firefox for Android 26.0: 	5711ms
Google Chrome 31: 		827ms
Opera for Android 16.0:		948ms

Comment 1

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Seems likely to be a timer resolution problem or a JIT problem to me.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Actually, this particular microbenchmark is probably just slow because of the way that we represent child lists as an array.  This benchmark exercises the worst-case behavior of this representation: it inserts tens of thousands of elements, one at a time, at the beginning of the list.  The result is that we spend all of our time in memmove, and if the platform has slow memory (which I bet the HTC desire does), that will really hurt.

I would be interested in the actual subtest results, not just the overall time, that you see on the HTC desire to verify that hypothesis.

If this is indeed what's going on, then this is not a terribly high priority, because this is not a common access pattern in real websites (for example real websites pretty much never have child lists this long).  And the right fix in this case is bug 651120.

Note also that the canonical home for this benchmark is http://www.hixie.ch/tests/adhoc/perf/dom/artificial/core/001.html

Comment 3

[Salar]

The results was with newly opened firefox; they're worse with recently closed tabs.

Total elapsed time: 7069ms
Breakdown (fraction shows time relative to append time):
  Append:  1.00; 1171ms
  Prepend: 2.44; 2855ms
  Index:   0.03; 37ms
  Insert:  1.77; 2069ms
  Remove:  0.80; 937ms

Comment 4

[Boris Zbarsky [:bzbarsky]]

OK, but what are the corresponding numbers for Chrome on the same hardware?

Comment 5

[Salar]

Sorry, my bad.

Chrome 31:
Total elapsed time: 938ms
Breakdown (fraction shows time relative to append time):
  Append:  1.00; 284ms
  Prepend: 0.89; 253ms
  Index:   0.15; 43ms
  Insert:  0.88; 250ms
  Remove:  0.38; 108ms


Opera 16:
Total elapsed time: 924ms
Breakdown (fraction shows time relative to append time):
  Append:  1.00; 228ms
  Prepend: 1.12; 256ms
  Index:   0.20; 46ms
  Insert:  1.18; 268ms
  Remove:  0.55; 126ms


Puffin Browser 3.0.10154M
Total elapsed time: 2654ms
Breakdown (fraction shows time relative to append time):
  Append:  1.00; 11ms
  Prepend: 1.00; 11ms
  Index:   0.73; 8ms
  Insert:  1.73; 19ms
  Remove:  236.82; 2605ms

Comment 6

[Boris Zbarsky [:bzbarsky]]

OK.  So it's worth looking at the difference in the "Append" case, for sure.  And "Puffin Browser" seems to have a broken date implementation or something...

Mark, is it possible to get a profile of this thing on Android?

Comment 7

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Boris Zbarsky [:bz] (Vacation Dec 19 to Jan 1) from comment #6)
> OK.  So it's worth looking at the difference in the "Append" case, for sure.
> And "Puffin Browser" seems to have a broken date implementation or
> something...
> 
> Mark, is it possible to get a profile of this thing on Android?

I managed to get a profile:
http://people.mozilla.org/~bgirard/cleopatra/#report=97cbad39df2fc52fac2c4464183a5fe61bd3e866

The test() call starts at:
Startup::XRE_Main > Timer::Fire > js::RunScript

Comment 8

[Mark Finkle (:mfinkle) (use needinfo?)]

That profile is from a Nexus 4 running Android 4.4.2

Comment 9

[Boris Zbarsky [:bzbarsky]]

Hrm.  That profile shows 7% of the time is spent under testAppend(), but the actual leaves under there don't seem to show any obvious hotspots and the self time is 0.

Contrast with testInsert, which clearly shows a hotspot in bcopy... though only for half the total time(!).

Why do we have calls out to java_org_mozilla_gecko_gfx_NativePanZoomController_getRedrwaHint under testAppend?

Comment 10

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Vacation Dec 19 to Jan 1 from comment #9)
> Hrm.  That profile shows 7% of the time is spent under testAppend(), but the
> actual leaves under there don't seem to show any obvious hotspots and the
> self time is 0.
> 
> Contrast with testInsert, which clearly shows a hotspot in bcopy... though
> only for half the total time(!).
> 
> Why do we have calls out to
> java_org_mozilla_gecko_gfx_NativePanZoomController_getRedrwaHint under
> testAppend?

I really don't know, but looking at the code, we _might_ bet getting into NativePanZoomController_getRedrawHint from a geometryChanged call. Maybe the changes in the DOM are being seen as a screen size change?

http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/gfx/GeckoLayerClient.java#730
calls
http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/gfx/GeckoLayerClient.java#177

Do we have a bug filed on this performance issue for Desktop Firefox? I see significant differences between desktop Firefox (~230ms total) and Chrome (~40ms total).

Comment 11

[Mark Finkle (:mfinkle) (use needinfo?)]

Kats - Any idea on the NativePanZoomController_getRedrawHint question?

Comment 12

[Kartikaya Gupta (email:[e-mail])]

Uh, I can see no reason whatsoever that function should be getting called. At all. That code is disabled on Fennec. I can only assume this is a symbolication error of some sort. BenWa?

Comment 13

[Kartikaya Gupta (email:[e-mail])]

(In reply to Mark Finkle (:mfinkle) from comment #10)
> I really don't know, but looking at the code, we _might_ bet getting into
> NativePanZoomController_getRedrawHint from a geometryChanged call. Maybe the
> changes in the DOM are being seen as a screen size change?
> 
> http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/gfx/
> GeckoLayerClient.java#730
> calls
> http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/gfx/
> GeckoLayerClient.java#177
> 

(Note that on Fennec we are still using the JavaPanZoomController, not the NativePanZoomController, so the call at line 177 above should hit http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/gfx/JavaPanZoomController.java#1308)

Comment 14

[Benoit Girard (:BenWa)]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #12)
> Uh, I can see no reason whatsoever that function should be getting called.
> At all. That code is disabled on Fennec. I can only assume this is a
> symbolication error of some sort. BenWa?

Yes it is, it a bad interaction with elfhack and the profiler. We had profiler working on elfhack binaries at some point but it looks like we regressed. We could profile again with a non elfhack binary to get better symbol.

The current poorly symbolicate profile doesn't show a hotspot but a properly symbolicate profile *might*.

Comment 15

[Boris Zbarsky [:bzbarsky]]

> Do we have a bug filed on this performance issue for Desktop Firefox?

Yes, bug 651120.  The thing this bug depends on.

Again, I'm only really interested in the append part of this test; poor performance on the remove/insert/prepend bits is expected.

Comment 16

[Salar]

> Do we have a bug filed on this performance issue for Desktop Firefox?
https://bugzilla.mozilla.org/show_bug.cgi?id=606503
https://bugzilla.mozilla.org/show_bug.cgi?id=606474

Comment 17

[Boris Zbarsky [:bzbarsky]]

Bug 606503 is a bug in an add-on, not in Desktop Firefox.

Comment 18

[Salar]

Any news on this?
Using Firefox 29 have same results.

Comment 19

[Salar]

*has
:D

Comment 20

[Salar]

It is Firefox 33 and still no one is interested in having a deep look?
The results are the same.

Comment 21

[Salar]

Firefox 35 on BlueStacks emulator:
Total elapsed time: 3240ms
Breakdown (fraction shows time relative to append time):
  Append:  1.00; 490ms
  Prepend: 2.39; 1170ms
  Index:   0.06; 30ms
  Insert:  2.04; 1000ms
  Remove:  1.12; 550ms

Android 4.4.2 browser on BlueStacks emulator:
Total elapsed time: 90ms
Breakdown (fraction shows time relative to append time):
  Append:  1.00; 50ms
  Prepend: 0.20; 10ms
  Index:   0.00; 0ms
  Insert:  0.60; 30ms
  Remove:  0.00; 0ms


I thing one of the reasons Firefox feels a little slower on Android is the DOM operations. Please someone pay more attention to this.

Comment 22

[Firefox Bug Husbandry Bot]

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

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.

Comment 23

[Olli Pettay [:smaug][[e-mail]]]

On Android we're still a bit slower. On Linux Nightly seems to be faster than Chrome.

Comment 24

[Dave Hunt [:davehunt] [he/him] ⌚BST]

The Performance Impact Calculator has determined this bug's performance impact to be none. If you'd like to request re-triage, you can reset the Performance Impact flag to "?" or needinfo the triage sheriff.

Platforms: Android
Websites affected: Rare