Community
Participate
Working Groups
EDT JS runtime is downloaded as multiple small js files in sequence. This potentially has a performance problem. Recent performance tests with DojoSample shows that EDT runs a little big slower then RBD. We need a more deep investigation on the two difference approaches (download runtime as one big js, or download as separate small js.).
(In reply to comment #1) > EDT JS runtime is downloaded as multiple small js files in sequence. This > potentially has a performance problem. Recent performance tests with DojoSample > shows that EDT runs a little big slower then RBD. We need a more deep bit > investigation on the two difference approaches (download runtime as one big js, > or download as separate small js.).
I did some experiment to combine the runtime into one file. Currently, we have 65 js files for the EGL runtime, after combined, the size is about 700k. I can see VE is visibly faster when using the combined runtime. I also believe using a combined runtime will make the VE performance problem described in bug 360348 less likely to happen. Brian and I have discussed two solutions to do this. Solution A. We have to create a real combined runtime js file, and put it in plugin /org.eclipse.edt.runtime.javascript/runtime. It is very straight forward. We don't have to modify any VE or Deployment code. Just little modification to the generate the HTML so it load the combined runtime instead of 65 separate files. However, somebody has to keep the combined file up-to-date whenever anything is changed in one of the 65 runtime js files. We might be able to do this in build, or use ant script to help Solution B. We can add some logic in FileLocator so that it will automatically assemble a combined runtime file at initialization. We have build some nice infrastructure so that our VE or Deployer always looking for files through FileLocator. This solution would not require any "maintenance" effort in the future. I'm attaching a patch for solution B.
Created attachment 207021 [details] combine js runtime
I think I prefer solution B; it aids in development such that when we change the runtime files we don't need to run any scripts to recreate the big file for our workspace. It also prevents adding yet more "magic" to the builds.
I ran some tests with Tony's patch. I had the HTML generator inject some timestamps right before and right after files are downloaded and the page is displayed. I used a small, medium, and large handler to see if it's a percentage gain or a flat gain. XULRunner and WebKit had similar numbers. Small app: ONE FILE: 83 MANY FILES: 183 faster by 100ms Medium app: ONE FILE: 730 MANY FILES: 840 faster by 110ms Large app: ONE FILE: 1950 MANY FILES: 2100 faster by 150ms For small apps it does feel snappier, but once you have several widgets the gain is much less. If you think about a page with 20 TextFields, it only downloads TextField.js once and then renders 20 widgets. Thus larger apps have smaller savings because most of the wait is on the rendering and not the download. I'd be interested to hear others opinions on how much better it feels with "real" apps.
Justin, I did similar measurement as you did. The result shows that there's a flat gain around 250ms. I'm measuring the time from HTML file is generated to EVServer gets the first ___getevent from browser. (the difference with your number is probably because of different machine performance). 1 widget ONE FILE: 378ms MANY FILES: 641ms faster by: 263ms 13 widgets ONE FILE: 688 MANY FILES: 941ms faster by: 253ms 13 widgets ONE FILE: 688 MANY FILES: 941ms faster by: 253ms 11 widgets(101 instances) ONE FILE: 589 MANY FILES: 826ms faster by: 237ms Although this does not seem to be a huge improvement, I'm still interested in putting this into 0.7. To get good user experience with VE, we really need the response time to be sub seconds, and to get to that, 250ms is also important. In deployed application, there's usually a bigger network latency. If we are doing too many round trip with the server, it could hurt the performance.
I tried the patch. The size of the combined .js file is really big (711KB). 81KB of it is related to org.eclipse.edt.eunit.runtime -- is this necessary during dev/debug/deployment? We should also investigate how to minify the combined .js file --- I bet we could cut it down by 50% if it was minified.
jscompress.com takes the combined JS from 711KB to 325KB. Without eunit-related code, the compressed size becomes 265KB. (Not suggesting we use jscompress, but pointing out the significant size reduction if we use something)
(In reply to comment #9) > jscompress.com takes the combined JS from 711KB to 325KB. Without eunit-related > code, the compressed size becomes 265KB. > > (Not suggesting we use jscompress, but pointing out the significant size > reduction if we use something) Compress the JS file will require additional CPU time in both server & browser side. Since our VE is in the same machine, download the JS file would not spend too much of time.
It would probably be good to do some measurements to prove that out (so, measure the time it takes to serve up the compressed vs. uncompressed file). Also, I would think the browser would spend less time (who knows how much) parsing 250KB vs. 700KB. So, I tend to think there is value in making the file as small as possible.
It looks like the constant for Constants.RUI_RUNTIME_JAVASCRIPT_ALL_IN_ONE_FILE is missing.
Part of patch got into cvs together with Justin's fix for another issue. I just checkin the rest files so there won't be a compiling problem. The function is turned off by a flag in the code. We can turn that on after we decided to ship it.
We are not doing shinksafe because it needs CQ and was too late to start it when we realize. Neither are we doing compress probably because it was too late in 0.7. Both are proved feature for performance improvement in RBD. I think the target is to get both into the next release. combine runtime is just another performance improvement attempt. And all these 3 can be applied separately, does not needs to depend on each other. (In reply to comment #11) > It would probably be good to do some measurements to prove that out (so, > measure the time it takes to serve up the compressed vs. uncompressed file). > > Also, I would think the browser would spend less time (who knows how much) > parsing 250KB vs. 700KB. So, I tend to think there is value in making the file > as small as possible.
I did not notice that the file I modified also had Tony's change - that should not have been committed. Also, right now the flag to use a single big file is on not off. Should I turn it off? (The flag's purpose was to make it easy to switch back and forth for the performance testing)
After speaking with Brian, we'll leave it enabled for now. I put in a small change to FileLocator.java - the temp files were not being deleted on shutdown so after starting Eclipse several times I noticed lots of those 700k files in /tmp. I added: allInOneFile.deleteOnExit();
It's a good catch. Thanks!
Closing this bug, the fix is in.
