#10770 closed enhancement (wontfix)
Investigate re-ordering build file
Reported by: | dcherman | Owned by: | |
---|---|---|---|
Priority: | low | Milestone: | None |
Component: | build | Version: | 1.7 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description (last modified by )
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.
http://en.wikipedia.org/wiki/DEFLATE#Duplicate_string_elimination
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 (8)
comment:1 Changed 11 years ago by
Component: | unfiled → build |
---|---|
Keywords: | 1.8-discuss added |
Priority: | undecided → low |
Status: | new → open |
Version: | git → 1.7 |
comment:2 Changed 11 years ago by
Description: | modified (diff) |
---|
comment:4 Changed 11 years ago by
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 11 years ago by
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.
comment:8 Changed 11 years ago by
Keywords: | 1.8-discuss removed |
---|---|
Resolution: | → wontfix |
Status: | open → closed |
-1, 140bytes is the upper bound? Sounds like a waste of time.