Bugzilla – Full Text Bug Listing
| Summary: | JS Runtime optimization | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Tony Chen <chenzhh> | ||||||||
| Component: | EDT | Assignee: | Project Inbox <edt.javascriptgen-inbox> | ||||||||
| Status: | NEW --- | QA Contact: | |||||||||
| Severity: | enhancement | ||||||||||
| Priority: | P3 | CC: | hjiyong, jvincens, mayunf, smythew, svihovec | ||||||||
| Version: | unspecified | ||||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows XP | ||||||||||
| Whiteboard: | RUI_Optimization | ||||||||||
| Bug Depends on: | 368167, 368168, 363317, 366740, 368166 | ||||||||||
| Bug Blocks: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Tony Chen
Created attachment 208988 [details]
analysis and design
I recall seeing a lot of EUnit-specific code in one of the EGL runtime JS files. We need to investigate whether this is always needed and how it might be separated out to further reduce the size of the JS runtime. There about 80KB EUnit code in runtime(total 740KB). After gzip & shrinksafe, the runtime is 73KB in total. The question falls into the discussion in page 7 of the doc. Can we include only runtime code which is used by the app? The answer is certainly we can. But this might not bring visible improvement for now. Let's say we removed EUnit, that might reduce the zipped runtime from 73KB to 65KB. (In reply to comment #2) > I recall seeing a lot of EUnit-specific code in one of the EGL runtime JS > files. We need to investigate whether this is always needed and how it might be > separated out to further reduce the size of the JS runtime. In regards to EUnit, I think we should make the decision based on whether it's truly needed or not (in general). Even though it's only a few KB (zipped), it's still 80 KB that must be parsed/processed by the browser (this becomes more of an issue with mobile devices). It may not make sense to break the rest of the runtime into pieces. The only question is with other 'heavy hitters' in the runtime, like BigDecimal, and whether all that code is typically needed (or only needed in limited situations). Tony - please add 'JS proxy optimization' to the list of areas to investigate. Two specific thoughts: 1) Do we *always* have to go back to the proxy for every request? The browser allows requests back to the same server the page came from (obviously), so if the RUI app needs to call some service (not dedicated, obviously) or get some resource from the same server, we should not have to go through our proxy. (I think) 2) What, if any improvements, can be made in the proxy code itself to make it run more optimally. For example, in bug 364666 (support for Google App Engine), I talk about how our proxy spawns a thread for every request it handles. This does not seem efficient (since the request into the proxy is already running in its own thread), but I know Joe had some reasons why he thought this was necessary (I have added him to this bug). Created attachment 209208 [details]
Updated design doc
Separate bugs are created for each problem identify for JS Runtime optimization. I added them to depends Bug 363317 - Add GZip support to the target server during deployment Bug 366740 - Shrinksafe Generated JavaScript During Deployment Bug 368167 - JS Runtime optimization: Include only necessary runtime code Bug 368168 - JS runtime optimization: proxy optimization Bug 368166 - Optimization of generated HTML file I think the latest design document summarizes the issues nicely. Can you elaborate on this statement on page 6, "Cache will be enabled for deployed app, with that, number of file might not be a big issue, most request does not go to server"? What kind of cache will be used, where will it be stored, etc? (A pointer to another bug with more details would be fine) I like the content on slides 3 and 4, and I think we should continue to expand on these numbers to show load times in various situations. For example, how much time is it taking to load the 24 files for a simple handler, which is mentioned on slide 6? How much time does it take to load these files from the browser cache? How much time does it take if we bundle all 24 files into a single .js file? Should we add a section on Dynamic Loading, so that we can consider how this feature might affect the design? One request we have seen in the past is the ability to bundle files that are being loaded dynamically into 'modules', which seems to be related to the question of 'Number of Files' on slide 6. This may not be an issue if the Dynamic Loading framework does not download .js files via the proxy, which would allow the browser to cache the contents. In regards to only including code that is required by an application, in the past we have discussed only including specific functions from files like egl.js, etc. I think this would be quite challenging, and not something we should consider any time soon, but it may be good to list in the design document for completeness. The Shrinksafe CQ is moving along, but we now need to file another CQ to use Rhino, which is required by Shrinksafe. The Eclipse Orbit project already provides a CQ for Rhino version 1.7R2, but Shrinksafe requires 1.7R1 and does not work with version 1.7R2. The Eclipse team has suggested that we ask the Shrinksafe team to produce a version for use with Rhino 1.7R2, or possibly look into alternate solutions, although requesting a CQ for Rhink 1.7R1 should also work. A list of JavaScript compressors can be found here: http://stackoverflow.com/questions/702907/what-are-some-good-css-and-js-minimizers-for-production-code Using the google closure compiler (http://closure-compiler.appspot.com/home), I had the following results for edt_runtime_all.js: Original Size: 660.82KB (121.61KB gzipped) Compiled Size: 324.11KB (61.56KB gzipped) (50% smaller for the non-gzipped file) Dojo Shrinksafe Online (http://dante.dojotoolkit.org/shrinksafe/) gives the following for the same file (it does not provide Gzip values) # Input Size: 739.09KB # Output Size: 389.24KB (47% smaller) The attached design document confirms the numbers for Dojo Shrink Safe, and indicates that the GZip output size is 73KB. I'm not sure why Google's Closure Compiler thinks that the initial file size is 660KB while Dojo thinks that it is 739KB. NOTE: The google closure compiler found 15 errors when trying to compile egl_development_all.js The YUI Compression utility (http://developer.yahoo.com/yui/compressor/) also requires Rhino, so that introduces the same CQ issues as Shrinksafe. It appears that the YUI Compression utility also supports minification of CSS files, which does not seem to be supported by Shrinksafe or Closure Compiler. Due to the fact that we have a lot of test effort already invested in Dojo Shrinksafe, and due to the fact that we need to open an additional CQ for all 3 of the options listed above, I am going to open a new CQ for Rhino 1.7R1 so that we can continue to use Shrinksafe. If we find that minifying CSS files will save a lot of time, we can open another CQ in the future for the YUI compressor. Cache in page 6 means the browser cache (I updated the doc to be more clear). Since the files(js,html,css) are deployed as static contents, most browsers will cache them. The biggest concern for file number is in a low bandwidth(and large latency) network environment. But with the browser cache, number of file only impact start time for first load which make it less important to further reduce file numbers. I updated the doc to add your thoughts of "only including specific functions" to page 7. add page 10 for some of my initial thoughts of dynamic loading. I will expand the analysis in page 3 & 4 with a more complex app, probably dojo sample. In that analysis, I'll try to include the time data (which does not seem to be very interesting for the simple handler being analyzed now). Thanks for the comments! (In reply to comment #9) > I think the latest design document summarizes the issues nicely. > > Can you elaborate on this statement on page 6, "Cache will be enabled for > deployed app, with that, number of file might not be a big issue, most request > does not go to server"? What kind of cache will be used, where will it be > stored, etc? (A pointer to another bug with more details would be fine) > > I like the content on slides 3 and 4, and I think we should continue to expand > on these numbers to show load times in various situations. For example, how > much time is it taking to load the 24 files for a simple handler, which is > mentioned on slide 6? How much time does it take to load these files from the > browser cache? How much time does it take if we bundle all 24 files into a > single .js file? > > Should we add a section on Dynamic Loading, so that we can consider how this > feature might affect the design? One request we have seen in the past is the > ability to bundle files that are being loaded dynamically into 'modules', which > seems to be related to the question of 'Number of Files' on slide 6. This may > not be an issue if the Dynamic Loading framework does not download .js files > via the proxy, which would allow the browser to cache the contents. > > In regards to only including code that is required by an application, in the > past we have discussed only including specific functions from files like > egl.js, etc. I think this would be quite challenging, and not something we > should consider any time soon, but it may be good to list in the design > document for completeness. > > The Shrinksafe CQ is moving along, but we now need to file another CQ to use > Rhino, which is required by Shrinksafe. The Eclipse Orbit project already > provides a CQ for Rhino version 1.7R2, but Shrinksafe requires 1.7R1 and does > not work with version 1.7R2. The Eclipse team has suggested that we ask the > Shrinksafe team to produce a version for use with Rhino 1.7R2, or possibly look > into alternate solutions, although requesting a CQ for Rhink 1.7R1 should also > work. Created attachment 209247 [details]
Updated design doc
|