I have an application whose 600k+ size dropped to about 100k for the initial download using code splitting. Not every app will benefit from code splitting, it really depends on how modular your app is - are there big pieces of functionality that stand alone, or is everything woven together?
I did need to look at the metrics. My initial attempt at code splitting showed no improvement, but after looking through the metrics I discovered that my onFailure() was calling some of my framework code...which then pulled in a ton of other framework code. Beware of displaying pretty dialogs in onFailure(), just use Window.alert()! Jeff On Tue, Feb 9, 2010 at 2:55 PM, Sky <[email protected]> wrote: > Bump > > I'm really curious if anyone can help me understand how code splitting > can be useful given the experience I have had with it. It really makes > little sense why the overhead is so huge. > > On Feb 5, 4:16 pm, Sky <[email protected]> wrote: >> 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. > > -- 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.
