Posts Tagged performance

GXT vs. GWT performance

I’ve recently been asked to dive deeply into GXT’s inherent performance problems again for some newer teams so I decided to build a simple GXT vs. GWT demo. Though I have piles of metrics from real-world use, this makes it really easy to compare the simplest use of widgets and eliminate any degradation (or optimization) that’s been added to individual applications over time. You can also see the full project on Google Code. I love App Engine for this kind of thing!

, ,

3 Comments

Java performance myths

Awhile back I posted a link to some good Java performance basics. Today at the office I saw an incredibly outdated JavaTM Performance Tuning and Java Optimization Tips from 1999 being circulated as a good read (that’s JDK 1.2!) and it made me cringe. I was inspired to dig up some Urban performance legends and then more Urban performance legends, revisited. A lot has changed in 10 years, and many things we used to lament over (think inlining source code) are far better left to the modern compiler.

,

No Comments

Stacking GWT 1.6 workers with ant parallel for super-fast builds

Having just built a new machine around a Core i7 950 enthusiastically overclocked to 4.2gz, I couldn’t help but explore the possibilities of a lightning-fast GWT compile. I regularly build a project that involves a core services war that’s pure Java along with a GWT 1.6 war consisting of two modules that requires 3 permutations each, all wrapped into an ear at the end.

Historically this took about 3 minutes running serially on a reasonable Core 2 Duo. It would run the core services war build, then the GWT build one module at a time, each using GWT 1.6′s -localWorkers 2 to at least make use of both cores.

The potential of 8 concurrent threads across the i7′s four cores and the presence of two GWT modules plus another build compelled me to resurect some old-school Ant parallelization to stack as much work as possible during the build. With a bit of tweaking it’s easy to have ant running multiple targets – some GWT and some non-GWT – at the same time, so that entire modules, not just permutations, are built in parallel. For example, something like

<target name="gwt">
	<java classname="com.google.gwt.dev.Compiler" fork="true" failonerror="false">
		<arg value="module1" />
		<arg value="-localWorkers" />
		<arg value="1" />
	</java>
	<java classname="com.google.gwt.dev.Compiler" fork="true" failonerror="false">
		<arg value="module2" />
		<arg value="-localWorkers" />
		<arg value="1" />
	</java>
</target>

becomes

<target name="gwt">
	<parallel threadsperprocessor="1">
		<java classname="com.google.gwt.dev.Compiler" fork="true" failonerror="false">
			<arg value="module1" />
			<arg value="-localWorkers" />
			<arg value="4" />
		</java>
		<java classname="com.google.gwt.dev.Compiler" fork="true" failonerror="false">
			<arg value="module2" />
			<arg value="-localWorkers" />
			<arg value="4" />
		</java>
	</parallel>
</target>

The result was phenomenal. My 3 minute build now takes only 40 seconds! If you have lots of cores available be sure to consider stacking ant parallel with GWT workers for a big improvement. Keep in mind that running many modules in parallel may also require ridiculous amounts of memory (around 600mb per module in my case), but on an i7 system you should have at least 6gb anyway right? :)

, , ,

4 Comments

Java performance basics

A good reminder of some little things in Java that can make a big performance difference, but are easy to forget:

Java Performance: The Return of the Usual Suspects (Updated)

,

No Comments