Posts Tagged gwt

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

Google IO 2010 day 2

Plenty more fun on day 2! There was lots of general iPhone and iPad killing with Android 2.2 demos during the keynote, along with the announcement of Google TV. The keynote is up here.

More on GWT from the sessions:

Widgets
There is lots of client-side performance improvement to be had using LayoutPanels, UIBinder, and ClientBundle. Another great workaround, which does have some risk and complexity for “maximum performance”, is innerHtml. The new components in 2.1+ help abstract that out so as consumers we don’t have to dip into innerHtml directly as often to get the benefits. There are also some good organization and code clarity benefits to UIBinder, like declarative views and replacing the monolithic app css file with bite-sized package files where possible.

Testing
This session made me happy because the testing best practices at Google seem to align really well with what my team is already doing. They stressed heavily using MVP to create unit-testable code and then test in a JVM as much as possible, keeping views so simple that there is very little which can break. They also use Selenium/WebDriver for high-level integration tests that walk through the app as a sanity check. There was a little bit of discussion about GWT unit tests (the compiled ones), by for the most part everyone agreed that they are too slow for the value they provide so it’s an intermediary step for special cases where not a whole lot of testing occurs. Most importantly teams should just acknowledge up front that there are multiple scopes of GWT tests and try to use them all correctly. Another good idea out of this was developing UI test harnesses for complex UI views, especially anything browser-specific or with performance constraints, so that it’s possible to write “Selenium unit tests” that bring up just the harness page with the widget and hit them really hard in a tightly controlled scenario rather than in the larger application (even a mock application).

GWT in Production Applications
This was Ray Ryan’s (of the infamous 2009 MVP session) architecture talk this year. The overall theme around MVP was the same, with some focus on broader topics like supporting bookmarkable/crawlable pages. However it was interesting to learn that GWT core is finally going to bring in some version of GWTLog that implements the Java logging API. The main tool used for demoing these was Spring Roo with GWT which in a nutshell is “Grails for GWT” – really cool to run a few commands and auto-generate your whole project, JPA entities, service endpoints, etc. but not something I’ll use on an existing, well-established product. For brand new products or teams just learning GWT it could be cool, and for the community overall certainly lowers the barrier of entry to get a full-stack Java/GWT project running quickly. Finally, in addition to logging there’s some new support in 2.1 for manipulating headers and some SafeHtml utils for using innerHtml in a way that doesn’t introduce security holes.

, , ,

No Comments

Google IO 2010 day 1

What a great way to kick off the conference! There was lots of GWT focus even starting during the keynote, which I honestly didn’t expect; HTML5 and browser video was big but GWT was right there behind it. Real backing from SpringSource/VMware was good to see and the SpeedTracer and 2.1 widget demos were impressive. The keynote is up on YouTube already, with sessions to follow in June.

My big takeaways the first day relating to GWT are:

Widgets
GWT 2.1 is just around the corner and is heavily performance-focused with more general purpose widgets that will let us display data quickly. Specifically they seem focused on high performance grids and layout strategies, which really started taking off in 2.0.

SpeedTracer
SpeedTracer has some really powerful new features like being able to add arbitrary benchmark points in code that show up in its UI, and ability to link back to the actual line of Java code for a GWT project (not just the obfuscated JS), along with the server-side integration via Spring from the keynote; while I haven’t tried yet it’s all in the latest milestone and should essentially be available now.

GWT Compiler
There are a lot of undocumented compiler options to further reduce code size and some other JVM options you might not have expected can help too (like -server and a 64-bit JVM), but using code splitting really makes the biggest difference (yay!), as well as some other things I’ve suspected like avoiding singletons and other static initializers at all cost.

GWT Linker
Linkers are really easy to build and are a powerful way to handle the final creation of an app with far more metadata available than, say, manipulating files with ant. Unfortunately something like static linking – an idea many of us have thought about to reduce the coupling between different GWT modules that inherit each other – needs heavy interaction between both the compiler and linker, and even though it’s open the core compiler is far less documented/outside developer friendly right now. However, there is really cool work being done to support distributed compiles that’s separating the work out in a way which might be divided not only among a cluster of machines across permutations, but used to save artifacts and re-use them if the underlying module hasn’t changed. I chatted with some people after the session and there is just a lot of work to be done in that smart splitting/change detection that puts it in at least the 2.2+ timeframe.

Architecting for Performance
Most of these best practices were things my team is already familiar with like putting serious thought into how the application is bootstrapped, how many RPCs we’re making, and what the payload is, specifically the importance of having UI-focused meta-services that return exactly what a UI function expects rather than simple generic services with heavy lifting in the client, plus more “use code splitting!”. However some new ideas are using UIBinder to separate out (and obfuscate, in production) css, using LazyPanel to defer rendering as late as possible without affecting the contract of widgets to their consumers, and designing UI’s with more optimism when an RPC takes place (assume it will work and begin the “success” case immediately, finishing as the data arrives, but potentially more work to handle failure).

A theme here was orders of magnitude, and the idea that performance is just a characteristic of usability:

  • 100ms = “instant” to users, almost everything should be faster than this – I related to this to anything that’s purely client that I expect to be unnoticeable
  • 1,000ms = “keeps focus”, this is a pretty big deal but things above this can be managed with explicit feedback – I related this to anything requiring a potentially slow RPC load and putting up some kind of “Searching…” or “Waiting…” dialog
  • 10,000ms = “upper limit”, the longest you can possibly ever take before a user has surely alt-tabbed, gotten up from their desk, force-killed your app, etc.!

HTML5
There’s a ton of buzz around this right now, but the short story for the moment is that any app forced to stay seriously in the IE7-8 world (which, sadly, mine does), is going to be crippled. To take advantage of what, as they like to say, “all modern browsers” are capable of, apps are going to need a user base comfortable running Chrome, Safari, and Firefox (and I guess Opera), else they’ll be left in the dust.

, , ,

No Comments

GWT 2.0 rocks

GWT 2.0 was just released ushering in some much-awaited changes like development mode in a real browser, code splitting, declarative UI, resource bundles, and HtmlUnit-based testing. My team just upgraded from 1.7.1 and the process couldn’t have been easier.

Unlike the massive type and project config changes in 1.6 there is very little that requires tweaking for 2.0. We simply swapped in the new gwt-user, gwt-servlet, and gwt-dev jars (just a config change since we finally use ivy), tweaked our Eclipse run configurations to add some new parameters for dev mode, and were off in running in IE 8, Firefox, and Chrome. Dev mode is a relief and way faster than the old IE-6-based hosted mode (best experienced in Chrome or Firefox but still an improvement in IE 8), and Speed Tracer provides an easy way to figure out what’s going on in the UI similar to Firebug Net mode. It’s also convenient to have everything the compiler needs on any OS wrapped into the single gwt-dev jar now, so no more gwt-dev-${os}.jar parameters in our build across different environments. We haven’t had a chance to play with the declarative UI but I can’t wait to see what it’s capable of.

But all the great new features aside, the most surprising aspect of the upgrade was that our entire codebase was already 100% compatible. Not only did this make “upgrading” the project a non-event, but the project can now go forward building on both GWT 2.0 and GWT 1.7. This includes not only our massive amounts of homegrown GWT code but also GWT incubator, GWT math, GXT, and a handful of other libraries we’re using. This is extremely powerful for us because we also export a client source jar with a limited set of widgets used by other projects, and they’re now free to upgrade GWT at their leisure. Even better, a GWT 1.7-compiled client can perform RPC calls seamlessly with a GWT 2.0 server using the existing 1.7 serialization policies, so all sorts of combinations of legacy clients hitting our latest and greatest server are possible. Long-term I’m sure everyone will want to be on 2.0 but it sure makes getting there easier!

Hats of to the team at Google for all their hard work and such a solid delivery.

3 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