Bug Tracker

Opened 9 years ago

Last modified 9 years ago

#10770 closed enhancement

Investigate re-ordering build file — at Version 5

Reported by: dcherman Owned by:
Priority: low Milestone: None
Component: build Version: 1.7
Keywords: Cc:
Blocked by: Blocking:

Description (last modified by mikesherov)

By changing the order that the various .js files are included, you can change the eventual gzipped output.

This is due to the way duplicate string elimination works on 32KB boundaries - since the minified source of jQuery will be greater than that, re-ordering them can change the results.


There's an existing pull request that reduces size by 140 gzipped bytes, however the re-ordering may be too drastic. That said, you can still improve the results by a lesser degree by moving a couple of them around.


Change History (5)

comment:1 Changed 9 years ago by timmywil

Component: unfiledbuild
Keywords: 1.8-discuss added
Priority: undecidedlow
Status: newopen
Version: git1.7

comment:2 Changed 9 years ago by jzaefferer

Description: modified (diff)

-1, 140bytes is the upper bound? Sounds like a waste of time.

comment:3 Changed 9 years ago by jaubourg

+0, I'd like to see big gains here.

comment:4 Changed 9 years ago by dmethvin

Description: modified (diff)

-1, Probably not worth the work, but I suspect we'll do a lot of reorg to the build process when Closure Compiler mods arrive.

comment:5 Changed 9 years ago by mikesherov

Description: modified (diff)

+1, this would require a centralized spot where we define the build order. currently, it's sprinkled around in several locations: the makefile, the unit tests, and soon in the JSHint checker. If the centralization occurs, I see no reason NOT to do this. To put this in context, I spent about 2 hours the other day golfing 40 bytes out of a pull request. 140 bytes is a big win IMO.

Note: See TracTickets for help on using tickets.