Sorry, I have to retract that last post entirely! I made a mistake in testing it when I removed that one line of code. I forgot that I was no longer actually calling GWT.runAsync() and thus it had gone back to it's original Initial download size. Even removing the "retry" code, but properly using GWT.runAsync() I encounter the original nightmare of overhead.
Sorry about the confusion. On Feb 5, 4:10 pm, Sky <[email protected]> wrote: > 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 <[email protected]> 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
