On Thu, Apr 23, 2009 at 8:32 PM, Dobes Vandermeer <[email protected]> wrote:
> Hi Vitali, > I have to test my CSS in all browsers, so I can't really work with one > permutation. Also, sometimes I need to make a last-minute patch before a > release and a 1-hour compile time would make that pretty much impossible. > Umm... CSS is trivial to test cross-browser. Compile it once & then screw around with the CSS file all you want (there's a javascript bookmark floating around on the internet I found that let's you reload the CSS file live on the page too, so you don't even need to restart your app). Throw more CPU power at the problem & your problem decreases. Make your build system a 16-way CPU & all the permutations become free. Even modern desktops have 2 cores which should help significantly. > > Also, if using a single permutation development is the "right way" to do > it, why is it such a pain to do? I have to create a separate module just > for that purpose ... it should just be a compiler argument. > Why is it hard? It is a compiler argument - you tell the compiler the module name. It's not as trivial for a one-off thing, but presumably you'll want to have multiple configurations & it would be faster to do those than to try compile-time arguments. Remember, permutation is not restricted to browser agent & localization - it's an arbitrary mechanism. You can add your own arbitrary Javascript code to define properties that add additional axes. It is an extremely powerful mechanism. The GWT module definition follows the spirirt of CSS in some ways with inheritance - so the closer you are to the top of the inheritance, the more precedance rules get. So you don't even need to maintain an actual module definition. just create one that inherits your main one & overrides the user agent & localization. > > > > On Thu, Apr 23, 2009 at 4:22 PM, Vitali Lovich <[email protected]> wrote: > >> I think you are not understanding the proper way to do this (it's on the >> docs btw for how Google uses it). You specify a specific permutation during >> development (i.e. english/firefox) so that compilation is super-fast (use a >> separate gwt.xml file with the rename-to option). When you compile all >> permuations, that's for deployment - happens much less frequently. Also it >> a very parallelizable operation, so add the localWorkers option to your >> project if you have more than 1 cpu - i.e. (-localWorkers 4). >> >> 2009/4/23 Dobes <[email protected]> >> >>> >>> I think it would be a lot better for my purposes to have a single >>> permutation and just have GWT.create() instantiate the right generated >>> subclass for the current browser/language setup. In fact, that would >>> cut my compile time down to just 2 or minutes. >>> >> How do you propose to do that? The whole point of GWT.create is that it >> is a compile-time substitution - it actually changes what code is >> generated. >> > > By doing a run-time substitution, of course. > Which defeats the whole purpose of the optimization part of GWT. The whole reason for doing GWT is that static analysis provides you with a lot more power. It's just stuff that's impossible at runtime (actually it's even worse cause you can't do any of that stuff statically with Javascript either because it lacks a statically typed system). > > >> Has anyone actually measured the benefits of compiling separately for >>> each browser as opposed to just using an appropriate subclass? >> >> They have - it was quite significant. But all these are just micro >> benchmarks, so they aren't going to give you an appropriate view of the >> impact on your application. >> > > Ah, any references to these where I could take a look at them? > The Google talks. The main developers behind them clearly outline the reasons & how powerful all this stuff makes GWT & all the stuff you get from these optimizations. > > >> A generic approach requires the traditional javascript way of doing >> unnecessary feature checks. >> > > I don't see how dynamically selecting a class to instantiate is any worse - > they are already doing those features checks when the js is loaded, they > would just defer class selection until runtime instead of compile time. > Functionally it's the same, except there are a few more classes included in > the compile, and some methods that can't be inlined since they might be > overridden in a subclass. > Look through the trunk - there's very good examples (DOMImpl & friends) of how it is used. Essentially, the optimization is so good that a lot of functions can be inlined to a 1 line piece of code while supporting multiple browsers. Also, there are no feature checks. It simply runs code to select the axes your configuration needs & does a hashmap lookup. It's extremely little overhead. The advantage is also that your browser will cache your entire application (optimized for that configuration) until it's changed by you - so whenever a user hits your site, they'll only ever download like 10K from your sever every time. This means not only is your code faster, you don't need to download a lot of unnecessary code that wouldn't be executed on the browser anyways. Remember, this is optimization, so it's not about providing equivalent functionality, but doing it in the fastest way possible. > >> Any idea how much work it would be to customize the compiler to work >>> this way? >> >> Not going to happen since it defeats the whole purpose of doing GWT. >> > > Actually the point of GWT is to develop in Java using the tools in the Java > IDE, permutations are just an optimization, in my opinion :-). > Yes there are two major parts to the reason for GWT. Java tooling is one. Optimization is the other major one. Go listen to the google talks. This is google after all - I don't think you can discount how much importance they tend to place on optimization. > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
