The 40+ languages situation really is unpleasant, and has lead us to devote a lot of time to squeezing every last ounce of performance out of the compiler. We've pitted our desire to let the compiler spend time optimizing code against the need to get things built in a reasonable amount of time, and we're in a continual struggle on the "reasonable amount of time" side. How have we convinced ourselves that a tight binary requires a permutation per language? Wouldn't a permutation per direction (rtl v.ltr) plus load time stitching of locale resources work just as well in the browser? It's not like loading the resources would have to happen via a separate browser request, they could be blended with the rest of the code by the server at request time.
I think I just suggested that the cache*html files become a template, with tokens swizzled for localized strings and data urls post compile, perhaps on demand. That sounds different than a linker to me--is it? rjrjr On Tue, Oct 20, 2009 at 6:59 AM, John Tamplin <j...@google.com> wrote: > On Tue, Oct 20, 2009 at 4:24 AM, Thoka <thobias.karls...@gmail.com> wrote: >> >> The initial problem was due to compile time and permutations. We just >> launched a GWT application with 43 languages, which generates about >> 43*6(?) permutations, and to get 43 languages (where each language has >> about 800 text and 300 configuration properties) entirely correct, >> this would generate a whole bunch of extra builds and server downtime >> each time a country wants to change even a very small thing as a >> misspelling. Perhaps this is not very useful when an application is >> perfectly in shape, configured and all texts are flawless, but while >> in developing/staging state it has saved us weeks of development since >> the customer is now able to internationalize their application "live" >> at staging/pre-prod state via an I18N-servlet, without the need to >> translate blindly and wait for the re-build and re-deploy for each >> batch. >> >> Perhaps this is not a feature for the common GWT developer, but as >> stated, it is very nice to have for larger applications. > > > I agree the situation you describe is an issue. A few points: > > - Doing a release build, with all the localizations, should only need > to be done when you are actually pushing a new build to production. All > your work can be done with a different module that limits the number of > locales (and user agents, depending on what sort of work you are doing) > during development. > - GWT is designed for parallel compilation. If you have a compile > cluster, you can build all the permutations in parallel so that the overall > build time is the same as one permutation if you have enough machines. > Instead of calling the Compiler entry point, you run Precompile on the > main > node, then CompilePerms on each permutation (they can all be run in > parallel), and then Link after all permutations have finished. If the > nodes > don't share a common filesystem, you have to do the work to copy the > precompilation.ser file to the permutation nodes and get all the artifacts > back from them to the main node. You also have to provide some glue for > your cluster/build system to make this happen, but the basic support is > there. Eventually we will probably provide more assistance in this area. > - Lex is working on changes to the Link phase which should (in theory) > allow incremental linking -- you could recompile just the permutation you > need to change and link it with the results of a previous compile, so if > all > you did was to change the German translations you could just rebuild those > permutations to get your compiled output. > > So, basically I agree that this is an issue but I think the best solution > is not to throw out compile-time evaluation/optimization but instead to use > the existing tools for parallel compilation, and for us to continue to > improve those tools. > > -- > John A. Tamplin > Software Engineer (GWT), Google > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
