876742 - JS performance regression beginning with AU91

Status: UNCONFIRMED

(Core :: DOM: Workers, defect, P5)

Description

[Mandyam Vikram]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0 (Beta/Release)
Build ID: 20130409194949

Steps to reproduce:

While profiling JS performance using Sunspider, we noticed a regression in JS performance beginning with AU91. Given below are the numbers we are seeing on a QRD device:

                           QRD B2G                                  QRD B2G
                      AU01.01.00.019.086                    AU01.01.00.019.091 
	
Sunspider                        2696	                            2933
(lower is better)


Actual results:

On analyzing this further, it was discovered that the fix for https://bugzilla.mozilla.org/show_bug.cgi?id=829482 was checked into AU91. This seems to be causing the lowered JS performance numbers. 


Expected results:

Backing this change out, improves the performance numbers. 

Changing “javascript.options.mem.gc_allocation_threshold_mb” parameter value as ‘3’ in AU91  in /gecko/b2g/app/b2g.js#567  seems to resolve this issue.

Comment 1

[Jason Smith [:jsmith]]

Ben - Any ideas?

Comment 2

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Yes, we changed the tuning on B2G on purpose so we're running GC more now. The previous values were tuned for desktop benchmark performance, and those values don't make sense on a severely memory-constrained device.

If sunspider numbers are really important then we can discuss the tradeoffs and such here.

Comment 3

[Mandyam Vikram]

As another point of reference, V8 numbers have regressed as well as below:

                           QRD B2G                                  QRD B2G
                      AU01.01.00.019.086                    AU01.01.00.019.091 
	
V8                            368                                  300
(higher is better)

The question is what effect this will have on overall browser as well as app performance in general.

Comment 4

[Justin Lebar (not reading bugmail)]

> The question is what effect this will have on overall browser as well as app performance 
> in general.

I think a better question is: Is the trade-off worth while?  Are we willing to accept a perf regression of this size (whatever it is) for an increase in stability of this size (whatever it is)?

I think the answer is probably yes.  But in any case we should not beg the question by focusing only on the downside of these changes.

Comment 5

[Mandyam Vikram]

I understand the memory v/s performance trade-off and for v1.1, may not be worth addressing. 
For subsequent releases, it would be beneficial to come to consensus on performance metrics for JS and the browser to set meaningful targets.

Comment 6

[Mandyam Vikram]

I would recommend that we close this issue for this product.