Efficient code splitting in a large application?

[socratesJ]

I'm attempting to implement code splitting with GIN in an Activities and Places context, using some of the ideas found here:

http://code.google.com/p/google-web-toolkit/issues/detail?id=5129

Due to the size of my application, I have around 50 split points corresponding to discrete Activities and/or views. According to the GWT compile report, I'm getting very little benefit from code splitting. Most of the code is getting shoved into the leftovers fragment, since so many of my split points share code. For instance, multiple split points have widgets built on top of common GXT widgets, so the GXT widget code ends up in the leftovers fragment, as it is not exclusive to any one split point.

My understanding is that if two or more split points share code, then that code can no longer be part of an exclusive fragment. As the number of split points grows, so too does the probability that 2 or more split points will share code, so this seems to be a case of rapidly diminishing returns as the number of split points grows.

Any suggestions on how to deal with this?

[RickL]

I spent over a week trying to come up with a solution to the large
left-overs fragment problem (I am using plain-vanilla gwt, not gxt).

In my opinion, this problem makes code-splitting as implemented only
marginally useful, at best. A lot of pain for very little gain.

If anyone has conquered this mountain, I would also like to hear from
them.

[Jens]

There is already a new code splitting algorithm in development that tries to conter this problem by merging split points that share a good amount of code and thus making this shared code exclusively to the newly merged split point.

That way you may define 50 split points in GWT but end up having only 18 real fragments generated where each of them is a bit bigger because it contains code that is currently in the leftover fragment or in the initial download fragment. So it tries to minimize both.

If you want a solution today, I think the only way to counter this problem is to reduce the number of split points. For example only make one split point for splitting login and app to make the login screen load faster and then add some more split points for the app's top level navigation items. 

Hopefully the new algorithm will do a good job in merging fragments and will be released (or at least be testable) in GWT 2.5. For code see:  http://code.google.com/p/google-web-toolkit/source/browse/trunk/dev/core/src/com/google/gwt/dev/jjs/impl/CodeSplitter2.java

-- J.

[kretel]

Jens, 

Do we have any indication when GWT 2.5 might be released (or at least RC) ?

Kris

[Jens]

There is no official release schedule or something similar.

You can only try to guess it yourself by:

- following the open issues for a given milestone on the issue tracker: 

http://code.google.com/p/google-web-toolkit/issues/list?can=2&q=milestone%3A2_5&sort=status&colspec=ID+Type+Status+Owner+Milestone+Summary+Stars&cells=tiles

- following GWT code reviews:

http://gwt-code-reviews.appspot.com/

- following the Google Web Toolkit Contributors group

-- J.

[Thomas Broyer]

See http://code.google.com/p/google-web-toolkit/issues/detail?id=7106#c2

[RickL]

Thank you very much for the good news, Jens and Thomas.

I had already limited my code splitting to trying to minimize the
initial login page load. The work you describe sounds like it will go
a long way toward making this much more practicable.

Now, if there was only an out-of-the-box manifest generating linker
and user-agent aware servlet that served the correct manifest for a
particular user-agent... ;-)

On Jan 11, 4:52 am, Thomas Broyer <t.bro...@gmail.com> wrote:
> Seehttp://code.google.com/p/google-web-toolkit/issues/detail?id=7106#c2