GWT Compilation Time Performance Improvement

[Niraj Salot]

Hi Members,

We are using GWT Version 2.4 in our current project. On server side, we are using Spring & Custom JDBC framework.

We are using Maven as our Build Tool. The application is getting deployed on JBOSS 7 Server.

Currently we have everything in one single Eclipse Project. Means one Application.gwt.xml file and one ApplicationContext.xml for spring. We have around 2000 Java files out of which around 1500 are for GWT related source files.

The project is still growing with more source files.

We are fine with timings of Java to Javac [class file] Compilation time. But when It comes to Java to JavaScript , It is a issue.

We have used all hacks mentioned in the GWT Forum.

Like.

1. Compiling for only one Local
2. Compiling for only one Browser

But still the compilation is taking 4-6 minutes.. OR even 7 minutes some times.

With this question, I would like to know the options available to improve the same.

We are thinking to Split the Project like this WAY:

• Module 1 (JAR Build)
• Module 2 (JAR Build)
• Module Main (WAR Build). This would contain Application.gwt.xml file which would inherit Module 1 & Module 2.

Now Question comes:

1) Will this help us in Improving the compilation time?

2) IF we change only Module 2 and then compile Module Main, will GWT still compile Module 1 as it is inherited by Module Main?

Please share your views on above scenario. We have even tried out GWT 2.5 option but no help in performance improvements.

Thanks, Niraj Salot.

[Hilco Wijbenga]

On 3 September 2012 23:10, Niraj Salot <salot...@gmail.com> wrote:
> 1) Will this help us in Improving the compilation time?

No.

> 2) IF we change only Module 2 and then compile Module Main, will GWT still
> compile Module 1 as it is inherited by Module Main?

Yes.

> Please share your views on above scenario. We have even tried out GWT 2.5
> option but no help in performance improvements.

You might want to check out code splitting (see [1]). I haven't tried
it but it *might* be possible to break up your app into separately
compiled modules.

What we really need is a linker that takes precompiled modules (each
stored in, say, a JAR) and combines them into an application. I know
this has been discussed but I am not aware of anyone actually working
on it. Unless code splitting already allows for all this...

[1] https://developers.google.com/web-toolkit/doc/latest/DevGuideCodeSplitting

[Thomas Broyer]

No. Code Splitting is about generating a bunch of JS scripts instead of a single one. The compilation process is still monolithic.

What could possibly help is to precompile the modules into *.gwtar files, but it's something that's supposed to only be used by GWT itself (you'll find such gwtar files in the gwt-user.jar) AFAIK. At least it's not designed to build "libraries", as the gwtar files depend on the version of GWT that produced them (IIUC).

No, really, 4-6 minutes is not that long given the size of the project, depending on the machine (number of cores/processors, memory, disks, etc.) and JVM tweaks (-Xmx, -Xms, etc.)

[Chris Lercher]

Another possibility would be to replace some classes with stubs (-> dependency injection) - only activating the functionality that is currently interesting. The rest doesn't need to be compiled. Of course it depends on the application's architecture, if this can be done easily or not.

[Abraham Lin]

What could possibly help is to precompile the modules into *.gwtar files, but it's something that's supposed to only be used by GWT itself (you'll find such gwtar files in the gwt-user.jar) AFAIK. At least it's not designed to build "libraries", as the gwtar files depend on the version of GWT that produced them (IIUC).

I've found that pre-compiling gwtar files has a negligible impact on overall compilation time, as most of the processing time is spent during the CompilePerms phase. Granted, this is dependent on the project architecture, but it seems unlikely that this will be a silver bullet for reducing overall compilation time (at least in its current state).

[Gal Dolber]

You could also move the compilation process to a bigger machine on the cloud and then if you need to run the compiled site locally do a script to download the content. That improved a lot the compilation time for me.

You can also try doing distributed builds (I personally never tried), but here are some links:

http://code.google.com/p/google-web-toolkit/wiki/DistributedBuilds

http://code.google.com/p/gwt-distcc/

https://github.com/markovuksanovic/gwt-distributed-compiler

On Tue, Sep 4, 2012 at 10:50 AM, Abraham Lin <atomknig...@gmail.com> wrote:

What could possibly help is to precompile the modules into *.gwtar files, but it's something that's supposed to only be used by GWT itself (you'll find such gwtar files in the gwt-user.jar) AFAIK. At least it's not designed to build "libraries", as the gwtar files depend on the version of GWT that produced them (IIUC).

I've found that pre-compiling gwtar files has a negligible impact on overall compilation time, as most of the processing time is spent during the CompilePerms phase. Granted, this is dependent on the project architecture, but it seems unlikely that this will be a silver bullet for reducing overall compilation time (at least in its current state).

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/RzBld5KNo6cJ.

To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--

A world citizen

[Ryan Shillington]

Niraj, you didn't mention the "-localWorkers" flag.   On a quad-core machine that reduced our compile time to about 1/3 of what it was (our 300s compile time became 100s).

Ryan

[Niraj Salot]

Hi Members,

Thanks for all your suggestion/comments.

We have already tried below mentioned options to improve the compilation time overall.

1. Memory Settings. -Xmx and Xms
2. localWorkers
   
3. DraftCompile

The question could arise to members mind that why we need to compile a lot but the thing is :- while doing the development work If we use the development mode provided by GWT , sometimes happens that the end output in production mode is diff. then development mode. So we can not trust that what is shown in development mode will be same in production mode. Hence developers compile their code on their machine and test it before putting something on main server. The issue is developers machine have overall RAM of 4 GB only. And when Jboss , Eclipse and Compilation of GWT runs , It is very very slow. So for even the small changes , developers needs to compile , build the WAR and then deploy to check that his code is working ok or not.

I am looking for some option which could allow me to pre-compile GWT modules. So that If some GWT module is not changed and when I compile the main module , that GWT module should not compile as it is not changed at all.

I am not still not getting how to use the concept of "*.gwtar files" which is mentioned in our discussion. Would appreciate if someone can provide more details on the same.

Thanks,Niraj.

[Paul Robinson]

Maybe you should get more RAM...4GB isn't a lot when running all the things you need for GWT development. Alternatively, run some (or even all) of the required processes on another computer.

Paul

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/xXHXkkCzV4oJ.

[Adolfo Panizo Touzon]

I don't know if I am missing something, but, have you tried to upgrade to GWT 2.5 and use SuperDevMode? In my case I was needing 2 minutes each time that I made any change and now 15 seconds(or less).

Maybe for your developers is worth to try it.

My 2 cents,

Adolfo.

2012/9/6 Paul Robinson <ukcu...@gmail.com>

--
El precio es lo que pagas. El valor es lo que recibes.
Warren Buffet

[Sebastián Gurin]

Niraj: IMHO if you want to agile GWT development you want to develop using the GWT devel mode or the GWT2.5 SuperDevMode (haven't tried myself) instead modify java -> compile with ant -> see the changes. You could ignore "devel mode vs production differences" when hard - developing, and perform a main compilation only after you finished a day's work or a module and test only for those kind of differences only in production mode.

Also, I would try to run the GWT devel mode using your external server application along with the rest of your webapp, instead builtin GWT server.

can I know what differences are those you are talking about ?

Regards and good look

[Chak Lai]

Instead of compiling one permutation at a time, there is an option to compile multiple permutations at the same time by mutli-process.

Here is the parameter I used in the Ant build.xml file (sorry, I don't use maven), all you needed to add -localWorkers within gwtc target tag:

<target name="gwtc" depends="javac" description="GWT compile to JavaScript (production mode)">

<java failonerror="true" fork="true" classname="com.google.gwt.dev.Compiler">

<classpath>

<pathelement location="src" />

<path refid="project.class.path" />

<pathelement location="C:/gwt-2.5.0.rc1/validation-api-1.0.0.GA.jar" />

<pathelement location="C:/gwt-2.5.0.rc1/validation-api-1.0.0.GA-sources.jar" />

</classpath>

<!-- add jvmarg -Xss16M or similar if you see a StackOverflowError -->

<!-- <jvmarg value="-Xmx256M"/> -->

<jvmarg value="-Xmx1024M" />

<arg line="-war" />

<arg value="war" />

<!-- Additional arguments like -style PRETTY or -logLevel DEBUG -->

<arg line="${gwt.args}" />

<!-- Number of process to compile -->

<arg value="-localWorkers" />

<arg value="2" />

<arg value="-optimize" />

<arg value="9" />

<arg value="-strict" />

<!-- <arg value="-XenableClosureCompiler" /> -->

<arg value="mta.itrac.Itrac" />

</java>

</target>

[Andy Stevko]

Have you considered using a SSD instead of a HD?

I've cut my compile times dramatically that way.

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/hhytunHdDYsJ.

To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--
-- A. Stevko

===========

"If everything seems under control, you're just not going fast enough." M. Andretti

[Andy Stevko]

Oh, and if you have to use an external device, use esata rather than usb.  while usb has higher burst  speeds, esata has much higher sustained transfer speeds.

[Niraj Salot]

Hi All,

I even tried upgrade of GWT 2.5 and SuperDevMode.

But Still no improvement.

Thanks.

On Tuesday, 4 September 2012 11:40:19 UTC+5:30, Niraj Salot wrote:

[Thomas Broyer]

On Friday, September 7, 2012 9:06:51 AM UTC+2, Niraj Salot wrote:

Hi All,

I even tried upgrade of GWT 2.5 and SuperDevMode.

But Still no improvement.

Really?! You mean that each time you hit the "DevMode On" bookmarklet and "Compile" button, it takes 4-6 minutes before the page is refreshed to reflect the changes you made in the code?

(launching SuperDevMode does a "full compile" –in draftMode though, and limited to user.agent=safari & locale=default– so it's expected to take some time, but you do it only once –or a very few times– per day)

Finally, you might want to setup "harnesses", i.e. small apps using only a portion of the code. That should speed up DevMode refreshes, SuperDevMode startup, and compilation; at the expense of not being your full app, so you cannot test/check everything.