Some quick observations from the docx: The bulk of your split points are sized pretty well, but if you can save the compiler work on those tiny ones and delete/merge them, that would be ideal, and may well help your leftovers.
That leftovers is quite large, but not totally out of control at least - only about 10-15% of the total JS output that a browser might run, but it does mean that in order to do anything you: * first download the .cache.html (a little over 5mb), start to use it, then for any one split point, * download entire leftovers chunk (11.5mb), then finally * download the specified split point Without knowing your application, I don't know if ~13mb is okay to download just to start using it, or how much separation there is between each split point - if you can be confident that a user in one split point will ever visit another, etc. If the user will typically visit many of them, this is probably okay, if they will just use one or two I'd want to look into different ways of structuring things. Seeing A, B, C, D sizes of your RPC services almost certainly points to the RPC situation that I had described, suggesting something like 90% overlap between so many RPC services is almost certainly points to a mistake in your RPC services or beans. Look for params in RPC services or fields in RPC beans that use raw generics, that reference Serializable or Comparable or some other abstract supertype with hundreds/thousands of subtypes. Easiest way to diagnose this would be to look over 580-590kb files and find one that you know should serialize fewer types than the giant list - you can search for the line saying "false, false, false, false" to find the exact RPC RemoteService implemented by that, then find some type which almost certainly doesnt belong there. From there you'll have to look over the types you _know_ belong there, and find the oversight. It is possible that you'll only have one or two things to fix for all of them (if it is one supertype that can just be modified slightly, like making it abstract or correcting some generics), but it may also be that you have many places to fix. To speed up compilation, try just adding <collapse-all-properties /> to the main .gwt.xml, and see if that keeps your code sizes roughly the same (but should cut something like half to 3/4ths of your compiled time off?). I don't have time today to go over the code samples, but this should give you some starting points at least to investigate. On Thursday, March 14, 2019 at 10:07:53 AM UTC-5, Vineet Jaiswal wrote: > > where as no. of code lines are concerned I can give you only an approx. > figure. > > 1. client + shared there might be minimum 10,00,000 lines code approx. > 2. server there might be minimum 50,000 lines code approx. > -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
