It appears I am wrong. If you notice this, don't bother reading my entire blurb above, instead learn from what I will explain here that was my mistake.
I put inside my onFailure() method a call to the method that calls GWT.runAsync() and creates the async "handler", effectively making it retry to download the code (limiting the number of retries of course before handling the error). Seemed like a good idea to retry because connection errors can happen and simply retrying may be successful. However, doing this clearly was my downfall and resulted in the terrible overhead and getting no reduction in the initial download size. By removing that one line of code the scenario completely reversed; the initial download size reduced appropriately and the Full code size increased only by 5kb. So, unless someone proposes a better way to "retry" without creating the above nightmare, I am not going to bother retrying. cheers On Feb 5, 3:57 pm, Sky <myonceinalifet...@gmail.com> wrote: > I successfully used code splitting on a few classes in my project. By > looking at the compilation report it appears to me that code splitting > has an incredibly large amount of overhead. > > I've gone through the report carefully and the code that I'm splitting > is indeed being split and not included in the Initial download. > > For the IE8 permutation, while splitting one 100 line class my Initial > download size jumped from 115kb to 141kb. That's 26kb and 22% increase > in my project size. Yeah the Full code size is indeed almost a 3kb > larger than the 141kb, though 10% of that is some code splitter code > that ends up being split along with class I split (and the widgets it > uses). > > Now, if I split another six 60 line classes you would think the > overhead wouldn't change much at all but it does. The initial download > size increases from the above 141kb to 145kb and the Full code size > increases from 144kb to 152kb. > > So ok, I would have expected that even if you split a gazillion small > pieces of code you would only pay for a fixed overhead on the async > code, but since I don't know how it works internally I can admit that > this may very well not be a good way to do code splitting. Similarly, > spinning off multiple threads/processes has a fixed amount of overhead > per thread/process in terms of memory used. > > However, I must complain that the overhead is just way too large. It > is 25% of my current project size. I estimate that maybe only around > 20-30% of my app will be able to be code split when I am done, but > because of this overhead that makes it completely pointless for me. It > appears that it would only be useful if your app becomes significantly > larger than 200kb. Maybe code splitting the odd 10kb of code here and > there with a total of 60kb isn't exactly saving a whole lot of space > off a 200kb app, but it would help the app to start up just that much > quicker. Besides, what about an app that will end up having hundreds > of those little 5-10kb "pages" that really only need to be lazy > loaded? > > Does anyone have anything to say or pointers on how to decrease the > overhead? Maybe I did something wrong, I am a novice at using GWT's > code splitting after all. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
