switching to dev mode took 41 seconds, chrome became responsive again about ~30 seconds after that. gut feeling wins.
2011/7/15 Rob Coops <[email protected]> > > > On Fri, Jul 15, 2011 at 1:23 PM, Dennis Haupt <[email protected]>wrote: > >> it's the speed. not the execution speed, that one is good enough. >> what i mean is the compilation speed. compiling my complete java project >> takes 30 seconds. compiling the tiny gwt part of it takes 91 seconds. >> activating the hosted mode takes about 1-2 minutes (didn't measure, feels >> like it). debugging like this takes forever. >> >> the write - test - debug - fix - cycle slows me down a lot. is there any >> way to fix that problem? >> >> -- >> 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. >> > > The speed of compilation and the starting in the dev server is indeed a > little slow, but then again if you look at what it is doing... > > Take Java code and transform that into javascript and html, then rinse and > repeat 6 times for all supported browsers and versions. Then repeat that n > times once for each language specified. In the end that means that where you > compile your java project once you compile your gwt bit at least six times > yet it only takes 3 times as long... > One thing I did to speed things up is remove all languages other then > default this saves a lot of compilation steps and reduces the time it takes > to compile significantly. After all once you have confirmed that a string is > translated there is little point in doing that again for every debug round. > > Another easy thing to do is reduce the compilation amount, do you really > need to recompile every single time? Most of the changes in your code can be > tested without having to recompile just redeploy the solution and all client > side code will/should (it does sometimes fail) run in the new updated > version. > Also pretty much all professional outfits use a nightly build to put the > whole lot together, build and deploy it all beyond that most of the time > developers work on their own portion of the code which they can compile and > test without always needing to compile the full project. > > Then there is one other thing which I know won't sound nice but it is true. > A gut feeling of 1 minute or even several minutes usually turns out to be > way less then that. Just like with performance testing you cannot trust your > feelings you have to measure things before you can say for sure. For > instance it has been found that one can make an application a lot faster by > showing the user a progress bar and status messages about what the program > is doing. The program is no faster but the user has the feeling stuff is > happening thus they feel that things are going faster even though there is > no factual difference in the execution speed. > So never trust a feeling, at least not when it comes to the measuring of > idle time waiting for a computer, as it is very often quite far of from > reality. > > Regards, > > Rob > > -- > 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.
