849873 - Further optimizations using a smarter minifier

Status: RESOLVED INCOMPLETE

(Firefox OS Graveyard :: Gaia, defect, P5)

Description

[Julien Wajsberg [:julienw]]

+++ This bug was initially created as a clone of Bug #837111 +++

Work begun with Closure Compiler as part of Bug 837111.

Comment 1

[Lukas Blakk [:lsblakk] use ?needinfo]

Not tracking, assuming that nom was carried over from cloning. If there's work here to consider for uplift please nominate at that time.

Comment 2

[Mike Lee [:mlee]]

Kevin, do we still need this?

Comment 3

[Kevin Grandon :kgrandon]

(In reply to Mike Lee [:mlee] from comment #2)
> Kevin, do we still need this?

I would recommend keeping this around for investigation. There is potential to shave off a few ms from every app launch here.

Comment 4

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

I was working today on memory usage for bug 914414 and decided to try to use uglifyjs2 instead of jsmin.

I don't have performance numbers yet, but memory wise it looks good.

	        master	uglify	delta
Main process	48.62	48.30	-0.32
Homescreen	16.50	16.30	-0.20
Settings	15.24	14.60	-0.64
Clock	        14.98	14.70	-0.28
Contacts	16.22	15.60	-0.62
Email    	18.56	18.30	-0.26
Music   	15.34	14.90	-0.44
Phone   	13.88	13.20	-0.68
Messages	14.00	13.90	-0.10
Browser   	 9.80	 9.80	 0.00

There's a minor bug with l10n.js that I'll need to hunt down (or wait for the refactor to land, since it works with it), but overall it seems like a clear win. 

The JS file size is smaller, memory wins are small but significant.
I'll get performance numbers tomorrow.

Comment 5

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

Attachment: uglifyjs.diff

This patch uses self-hosted https://github.com/mishoo/UglifyJS2 with added code from https://gist.github.com/jpillora/5652641 to provide minify() method.

Comment 6

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

Attachment: uglifyjs.diff

ahh, actually, I just bitrotted the patch with another patch.

Cleaned up it works against master!

Comment 7

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Zbigniew Braniecki [:gandalf] from comment #4)
> I don't have performance numbers yet, but memory wise it looks good.

Unless things have changed, SpiderMonkey still runs the source compressor-thread to recompress things.  While that compression has ramped down a lot for performance reasons, I would think the memory is the smallest concern.  The parse time and run-time of the source compressor (which runs on a different thread but blocks JS execution) I think are the most important metrics.

What method did you use to gather numbers?  Specifically, did you use the about:memory-style GC/CC mechanism to force the app to its lowest memory usage?  Your numbers seem like they could be well within expected GC noise.  Also, how many runs, how many seconds after app start, was the network off/apps in a quiescent initial start state, etc?

Comment 8

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

(In reply to Andrew Sutherland (:asuth) from comment #7)
> Unless things have changed, SpiderMonkey still runs the source
> compressor-thread to recompress things.  While that compression has ramped
> down a lot for performance reasons, I would think the memory is the smallest
> concern.  The parse time and run-time of the source compressor (which runs
> on a different thread but blocks JS execution) I think are the most
> important metrics.

I do agree.

From the numbers I see, the only one I'd consider important is that it does seem to shave 1MB of off b2g process which may be important for things like bug 929945.

> What method did you use to gather numbers?  Specifically, did you use the
> about:memory-style GC/CC mechanism to force the app to its lowest memory
> usage?

I use USS from b2g-info after waiting 20 sec after app launch. It's becoming stable at that point and is closer to real time scenario, right?

>  Your numbers seem like they could be well within expected GC noise. 
> Also, how many runs, how many seconds after app start, was the network
> off/apps in a quiescent initial start state, etc?

I do 10 runs, 20 sec delay, airplane mode.
I know it's not the major win, and the number of replications is low, but it's just a preliminary data. Once I have more, especially from b2hperf (where I do 31 replications) we may be able to tell if uglifyjs is beneficial.

Comment 9

[Julien Wajsberg [:julienw]]

(In reply to Andrew Sutherland (:asuth) from comment #7)
> The parse time and run-time of the source compressor (which runs
> on a different thread but blocks JS execution) I think are the most
> important metrics.

I agree, although normally uglifyjs2 output should work just as fine for this.

The only drawbacks I see with using uglifyjs2 (at least in its default mode) is that it changes variable names, which is not so good when we have issues reported by people using a production phone.

Comment 10

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

So, b2gperf, 30 replications, Keon, production, master vs. master+uglifyjs:

Settings 597 -> 585 = -12
Contacts 557 -> 548 = -9
Music    437 -> 428 = -9
Browser  435 -> 424 = -11

Comment 11

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Andrew Sutherland (:asuth) from comment #7)
> (In reply to Zbigniew Braniecki [:gandalf] from comment #4)
> > I don't have performance numbers yet, but memory wise it looks good.
> 
> Unless things have changed, SpiderMonkey still runs the source
> compressor-thread to recompress things.  While that compression has ramped
> down a lot for performance reasons, I would think the memory is the smallest
> concern.  The parse time and run-time of the source compressor (which runs
> on a different thread but blocks JS execution) I think are the most
> important metrics.

I don't think memory is the smallest concern due to our hard target. If we can save some bytes it sounds good to me, especially on some devices where once the memory limit is reached we start to swap a lot and performance are degrade.

So if we can combine small perfs win + some memory saving, that sounds good to me.

Gandalf do you have some free cycles to continue to work on that ?
> 
> What method did you use to gather numbers?  Specifically, did you use the
> about:memory-style GC/CC mechanism to force the app to its lowest memory
> usage?  Your numbers seem like they could be well within expected GC noise. 
> Also, how many runs, how many seconds after app start, was the network
> off/apps in a quiescent initial start state, etc?

Comment 12

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

Closing as incomplete