Re: How to deal with large multi-module applications on GWT
> All our developers have new core i7 machines with 8gb of RAM That's not enough. We used to use 16GB RAM for developers, but it was too constraining. We now use 32GB 64 bit machines. Having fast hardware makes a significant difference too. Paul On Fri, Jun 19, 2015 at 12:02 AM, Victor Krausser wrote: > Hello Jens! > > Well, today we have more than 250K java lines of client code divided in > around 50 modules compiled in 4 permutations (2 browsers and 2 languages). > > I would say that full clean-build, let's say for a release or in > continuous integration, could actually take up to 30 min and would not be a > problem. But I can not let this grow indefinitely in memory, it would be a > problem even for a server. > > Today I had to increase again maxHeapSize of the build as it surpassed > 3GB. All our developers have new core i7 machines with 8gb of RAM. For > dev we are working with strategies as commenting out groups of modules that > we are not working on to improve compile time and memory consumption. > > What we need is to structure better our projects to *decrease the memory > footprint for dev and CI environment and compile time for dev*. > We plan on increasing a lot our code base and with the current structure > it will really soon become unsustainable. > > > > Em quinta-feira, 11 de junho de 2015 19:32:59 UTC-3, Jens escreveu: >> >> AFAICT the amount of GWT modules shouldn't noticeably influence the >> compilation time. >> >> What increases compilation time is lines of code obviously, the amount of >> permutations that need to be compiled (for example I18n can produce lots of >> permutations), wether or not you use more than one worker during >> compilation (parameter -localWorkers) and finally outdated CPUs and RAM >> shortage (GWT developers should have decent machines to work with, not that >> 5 year old 3GB Windows 7 notebook). >> >> So for production builds or test builds you probably don't care about the >> compile time as these builds are done on build servers anyways. For the >> occasional development compiles you can decrease compilation time by >> limiting permutations to a single one and skip most optimizations by using >> the -draftCompile parameter. >> >> How many lines of client side GWT code does your app have and how many >> permutations do you produce? A compile time of 8-12 minutes doesn't sound >> too unreasonable if the app is already large or has lots of permutations. >> >> >> -- J. >> > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" 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 http://groups.google.com/group/google-web-toolkit. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" 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 http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: How to deal with large multi-module applications on GWT
I On Fri, Jun 19, 2015 at 4:32 AM, Victor Krausser wrote: > Hello Jens! > > Well, today we have more than 250K java lines of client code divided in > around 50 modules compiled in 4 permutations (2 browsers and 2 languages). > > I would say that full clean-build, let's say for a release or in > continuous integration, could actually take up to 30 min and would not be a > problem. But I can not let this grow indefinitely in memory, it would be a > problem even for a server. > > Today I had to increase again maxHeapSize of the build as it surpassed > 3GB. All our developers have new core i7 machines with 8gb of RAM. For > dev we are working with strategies as commenting out groups of modules that > we are not working on to improve compile time and memory consumption. > > What we need is to structure better our projects to *decrease the memory > footprint for dev and CI environment and compile time for dev*. > We plan on increasing a lot our code base and with the current structure > it will really soon become unsustainable. > > > > Em quinta-feira, 11 de junho de 2015 19:32:59 UTC-3, Jens escreveu: >> >> AFAICT the amount of GWT modules shouldn't noticeably influence the >> compilation time. >> >> What increases compilation time is lines of code obviously, the amount of >> permutations that need to be compiled (for example I18n can produce lots of >> permutations), wether or not you use more than one worker during >> compilation (parameter -localWorkers) and finally outdated CPUs and RAM >> shortage (GWT developers should have decent machines to work with, not that >> 5 year old 3GB Windows 7 notebook). >> >> So for production builds or test builds you probably don't care about the >> compile time as these builds are done on build servers anyways. For the >> occasional development compiles you can decrease compilation time by >> limiting permutations to a single one and skip most optimizations by using >> the -draftCompile parameter. >> >> How many lines of client side GWT code does your app have and how many >> permutations do you produce? A compile time of 8-12 minutes doesn't sound >> too unreasonable if the app is already large or has lots of permutations. >> >> >> -- J. >> > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" 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 http://groups.google.com/group/google-web-toolkit. > For more options, visit https://groups.google.com/d/optout. > I do not know whether the link below can help you to solve your problem, but you can just go through it http://www.slideshare.net/RobertKeane1/turducken-divide-and-conquer-large-gwt-apps-with-multiple-teams -Nagin -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" 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 http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: How to deal with large multi-module applications on GWT
Hello Jens! Well, today we have more than 250K java lines of client code divided in around 50 modules compiled in 4 permutations (2 browsers and 2 languages). I would say that full clean-build, let's say for a release or in continuous integration, could actually take up to 30 min and would not be a problem. But I can not let this grow indefinitely in memory, it would be a problem even for a server. Today I had to increase again maxHeapSize of the build as it surpassed 3GB. All our developers have new core i7 machines with 8gb of RAM. For dev we are working with strategies as commenting out groups of modules that we are not working on to improve compile time and memory consumption. What we need is to structure better our projects to *decrease the memory footprint for dev and CI environment and compile time for dev*. We plan on increasing a lot our code base and with the current structure it will really soon become unsustainable. Em quinta-feira, 11 de junho de 2015 19:32:59 UTC-3, Jens escreveu: > > AFAICT the amount of GWT modules shouldn't noticeably influence the > compilation time. > > What increases compilation time is lines of code obviously, the amount of > permutations that need to be compiled (for example I18n can produce lots of > permutations), wether or not you use more than one worker during > compilation (parameter -localWorkers) and finally outdated CPUs and RAM > shortage (GWT developers should have decent machines to work with, not that > 5 year old 3GB Windows 7 notebook). > > So for production builds or test builds you probably don't care about the > compile time as these builds are done on build servers anyways. For the > occasional development compiles you can decrease compilation time by > limiting permutations to a single one and skip most optimizations by using > the -draftCompile parameter. > > How many lines of client side GWT code does your app have and how many > permutations do you produce? A compile time of 8-12 minutes doesn't sound > too unreasonable if the app is already large or has lots of permutations. > > > -- J. > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" 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 http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: How to deal with large multi-module applications on GWT
AFAICT the amount of GWT modules shouldn't noticeably influence the compilation time. What increases compilation time is lines of code obviously, the amount of permutations that need to be compiled (for example I18n can produce lots of permutations), wether or not you use more than one worker during compilation (parameter -localWorkers) and finally outdated CPUs and RAM shortage (GWT developers should have decent machines to work with, not that 5 year old 3GB Windows 7 notebook). So for production builds or test builds you probably don't care about the compile time as these builds are done on build servers anyways. For the occasional development compiles you can decrease compilation time by limiting permutations to a single one and skip most optimizations by using the -draftCompile parameter. How many lines of client side GWT code does your app have and how many permutations do you produce? A compile time of 8-12 minutes doesn't sound too unreasonable if the app is already large or has lots of permutations. -- J. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" 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 http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
How to deal with large multi-module applications on GWT
Hello everyone! We are reaching out for suggestions for a new architectural approach for our software. Currently we are working on the development of a new front-end for our ERP, and our framework of choice on the time we started was GWT+GWTP for the front-end. Our first Idea was to have a single page application running a composed GWT application where functionalities were modules aligned beyond a main module. Now we are reaching a critical phase of the process where we are actually creating the system functionalities. But we are facing serious problem with this approach. At this point we have 41 GWT modules being compiled as dependencies of our main module with more that 3GB of ram and taking 8-12 minutes. We are expecting to have more that 400 modules at the end of the current development phase, and it will become unsustainable in terms of computer power to compile the application. Regards, Victor Krausser Software Architect -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" 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 http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
