4 ms·
I remember back in the day, Google Closure was so advanced they even tried out shuffling code around in the final JS file and measured which way produced the be
by susi22 10y ago
I remember back in the day, Google Closure was so advanced they even tried out shuffling code around in the final JS file and measured which way produced the best GZIP compression. They since abandoned that code though, but that's something they did over 5 years ago.
- dunham 10y agoThey do (or did) something similar with the back end of GWT (globally sorting method definitions by length). But it's probably easier with GWT output (vs arbitrary js), because it has a well defined structure.
- cromwellian 10y agoYou can see some of the original research I did on this in my old blog post: http://timepedia.blogspot.com/2009/08/on-reducing-size-of-compressed.html http://timepedia.blogspot.com/2009/08/on-reducing-size-of-co... I followed up by researching different clustering metrics including something called LZDIST instead of edit-distance. http://timepedia.blogspot.com/2009/11/traveling-salesman-problem-and.html http://timepedia.blogspot.com/2009/11/traveling-salesman-pro... I think it works better for GWT than for Closure because GWT's optimizer permits inlining functions in some circumstances even if they increase code size. This causes repetitious fragments to appear, and re-ordering the code to bring those fragments within GZIP's compression window functions as kind of a late-stage "anti-inliner/common subexpression elimination"