Closed
Bug 849873
Opened 12 years ago
Closed 9 years ago
Further optimizations using a smarter minifier
Categories
(Firefox OS Graveyard :: Gaia, defect, P5)
Tracking
(b2g18-)
RESOLVED
INCOMPLETE
Tracking | Status | |
---|---|---|
b2g18 | - | --- |
People
(Reporter: julienw, Unassigned)
References
Details
(Keywords: perf, Whiteboard: [c= p= s= u=])
Attachments
(1 file, 1 obsolete file)
269.66 KB,
patch
|
Details | Diff | Splinter Review |
+++ This bug was initially created as a clone of Bug #837111 +++
Work begun with Closure Compiler as part of Bug 837111.
Reporter | ||
Updated•12 years ago
|
Assignee: nobody → 21
Reporter | ||
Updated•12 years ago
|
Flags: needinfo?(21)
Comment 1•12 years ago
|
||
Not tracking, assuming that nom was carried over from cloning. If there's work here to consider for uplift please nominate at that time.
Flags: needinfo?(21)
Updated•11 years ago
|
Whiteboard: [FFOS_perf] c= → [c= ]
Updated•11 years ago
|
Status: NEW → ASSIGNED
Comment 2•11 years ago
|
||
Kevin, do we still need this?
Assignee: 21 → nobody
Status: ASSIGNED → NEW
Flags: needinfo?(kgrandon)
Priority: -- → P5
Whiteboard: [c= ] → [c= p= s= u=]
Comment 3•11 years ago
|
||
(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.
Flags: needinfo?(kgrandon)
Comment 4•11 years ago
|
||
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•11 years ago
|
||
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•11 years ago
|
||
ahh, actually, I just bitrotted the patch with another patch.
Cleaned up it works against master!
Attachment #8335733 -
Attachment is obsolete: true
Comment 7•11 years ago
|
||
(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•11 years ago
|
||
(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.
Reporter | ||
Comment 9•11 years ago
|
||
(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•11 years ago
|
||
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•11 years ago
|
||
(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?
Flags: needinfo?(gandalf)
Comment 12•9 years ago
|
||
Closing as incomplete
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(gandalf)
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•