Tapestry Training -- From The Source

Let me help you get your team up to speed in Tapestry ... fast. Visit howardlewisship.com for details on training, mentoring and support!

Wednesday, September 16, 2009

Tapestry Performance Benchmark (vs. Wicket, JSF, etc.)

Peter Thomas has created a detailed performance analysis of Wicket, Tapestry, Grails and Seam. It's an interesting read from non-Tapestry user's perspective, and complements Ben Gidley's findings.

He's measuring raw performance and Wicket narrowly bests Tapestry in most categories, with Seam pretty close and Grails much further out.

I'm disturbed by some of his problems developing the application (with respect to adding client-side credit card number validation) and there's no mention of Tapestry's other qualities, such as live class reloading, exception reporting, etc. Still, criticism of Tapestry's documentation hits close to home (and it, alas, too fair). Accurate and very complete, but not organized for a beginner ... something I'm hoping to address over the next few months.

4 comments:

Kalle Korhonen said...

However you look at the data, Wicket looks pretty good. Heap usage aside, Howard do you think that there any more reasonably low hanging fruits to squeeze some more performance out of T5?

Howard said...

I'm sure there's a few odd corners that could be made more efficient. However, my time is actually better spent on making Tapestry easier to use, and that means documentation (both online and in book form).

One thing that would likely help is the mechanism I've talked about before ... to allow client-side state to be represented as a short token to a server-side value (stored in an efficient database such as BerkelyDB). This would reduce the amount of time spent converting such data to a string format (which involved GZip compression and encoding) as well as the time to convert it back to objects. That would help with rendering forms as well as form submissions.

There may be room to improve performance by getting rid of pipelines and filters and moving more code into large blocks ... but that's not going to happen, in fact, just the opposite, more services, more pipelines, more "seams" that allow for extensions and overrides.

Thiago H de Paula Figueiredo (Thiago HP) said...

Hi!

The aspect of that comparison that I really don't get is the session usage: Tapestry consumes a little bit less than Wicket, but T5 itself doesn't use the session, while Wicket does.

Howard said...

It is interesting; the question is what he was storing in the session, and why. The code is available but I absolutely don't have time to figure it out (I'm balancing multiple clients right now).


I would doubt he tuned the application as well as Ben did.