You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Howard <hl...@gmail.com> on 2009/09/16 22:07:40 UTC

[Tapestry Central] 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.

--
Posted By Howard to Tapestry Central at 9/16/2009 12:59:00 PM

Re: [Tapestry Central] Tapestry Performance Benchmark (vs. Wicket, JSF, etc.)

Posted by Michael Gentry <mg...@masslight.net>.
This is the link?

http://ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-5-and-grails/


On Wed, Sep 16, 2009 at 4:07 PM, Howard <hl...@gmail.com> wrote:
> 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.
>
> --
> Posted By Howard to Tapestry Central at 9/16/2009 12:59:00 PM

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: [Tapestry Central] Tapestry Performance Benchmark (vs. Wicket, JSF, etc.)

Posted by Josh Canfield <jo...@thedailytube.com>.
> You're right. Maybe we should change the default tracker persistence from
> session to flash persistence? I do that in my projects using @Meta.

Personally I wish the form didn't persist anything until it needed it
so the session wasn't created. Client persistence isn't an option
because of the nasty urls. Whether it's flash or session is really up
to the particular forms usage. I've posted my implementation of a form
that doesn't persist the tracker until there is something to be
tracked before. I have a site with a search box and that is mostly
view only so creating a session for all those views is no good.

Josh
-- 
--
TheDailyTube.com. Sign up and get the best new videos on the internet
delivered fresh to your inbox.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: [Tapestry Central] Tapestry Performance Benchmark (vs. Wicket, JSF, etc.)

Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Fri, 18 Sep 2009 19:57:41 -0300, Josh Canfield <jo...@thedailytube.com>  
escreveu:

> Last time I checked the Form component persists the tracker, which
> means rendering a form puts something in your session. Every page in
> the test has a form and so a different tracker would be persisted.

You're right. Maybe we should change the default tracker persistence from  
session to flash persistence? I do that in my projects using @Meta.

> I haven't done any testing to see how much heap this is actually
> consuming, but I can't imagine that its too much. even with 20
> sessions and 7 pages that should only be 140 trackers, right?

ValidationTrackerImpl has the following non-transient fields:

private List<String> extraErrors;

private List<FieldTracker> fieldTrackers;

FieldTracker is an inner class inside ValidationTrackerImpl:

     private static class FieldTracker implements Serializable
     {
         private static final long serialVersionUID = -3653306147088451811L;

         private final String fieldName;

         private String input;

         private String errorMessage;

         FieldTracker(String fieldName)
         {
             this.fieldName = fieldName;
         }
     }

-- 
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: [Tapestry Central] Tapestry Performance Benchmark (vs. Wicket, JSF, etc.)

Posted by Josh Canfield <jo...@thedailytube.com>.
> T5 doesn't use the session itself. That's exactly what puzzles me.

Last time I checked the Form component persists the tracker, which
means rendering a form puts something in your session. Every page in
the test has a form and so a different tracker would be persisted.

I haven't done any testing to see how much heap this is actually
consuming, but I can't imagine that its too much. even with 20
sessions and 7 pages that should only be 140 trackers, right?


Josh


On Thu, Sep 17, 2009 at 4:44 PM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> Em Thu, 17 Sep 2009 18:31:11 -0300, Norman Franke <no...@myasd.com>
> escreveu:
>
>> I'm puzzled by the retained size for 20 sessions.
>
> Me too . . .
>
>> Is that due to how
>> he wrote the app and marked everything as @Persist, or is T5 really
>> that bad?
>
> T5 doesn't use the session itself. That's exactly what puzzles me.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>



-- 
--
TheDailyTube.com. Sign up and get the best new videos on the internet
delivered fresh to your inbox.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: [Tapestry Central] Tapestry Performance Benchmark (vs. Wicket, JSF, etc.)

Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 17 Sep 2009 18:31:11 -0300, Norman Franke <no...@myasd.com>  
escreveu:

> I'm puzzled by the retained size for 20 sessions.

Me too . . .

> Is that due to how
> he wrote the app and marked everything as @Persist, or is T5 really
> that bad?

T5 doesn't use the session itself. That's exactly what puzzles me.

-- 
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: [Tapestry Central] Tapestry Performance Benchmark (vs. Wicket, JSF, etc.)

Posted by Howard Lewis Ship <hl...@gmail.com>.
It's a mix; he's storing a lot of WebFlow style data in the session/  I
haven't looked at his code (it is downloadable) to see what else he is
doing. Ben Gidley's detailed T5 analysis didn't note an exceptional memory
utilization.
On Thu, Sep 17, 2009 at 2:31 PM, Norman Franke <no...@myasd.com> wrote:

> I'm puzzled by the retained size for 20 sessions. Is that due to how he
> wrote the app and marked everything as @Persist, or is T5 really that bad? I
> know I try to minimize the use of @Persist, but the post-redirect model
> makes this much more difficult, seriously impairing one key aspect of what
> makes T5 scalable. I've done a lot with T4 and pretty much never persisted
> anything in the session except the login state and any servlet overhead.
>
> Norman Franke
> Answering Service for Directors, Inc.
> www.myasd.com
>
>
>
>
> On Sep 16, 2009, at 4:07 PM, Howard wrote:
>
>  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.
>>
>> --
>> Posted By Howard to Tapestry Central at 9/16/2009 12:59:00 PM
>>
>
>


-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to learn
how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com

Re: [Tapestry Central] Tapestry Performance Benchmark (vs. Wicket, JSF, etc.)

Posted by Norman Franke <no...@myasd.com>.
I'm puzzled by the retained size for 20 sessions. Is that due to how  
he wrote the app and marked everything as @Persist, or is T5 really  
that bad? I know I try to minimize the use of @Persist, but the post- 
redirect model makes this much more difficult, seriously impairing one  
key aspect of what makes T5 scalable. I've done a lot with T4 and  
pretty much never persisted anything in the session except the login  
state and any servlet overhead.

Norman Franke
Answering Service for Directors, Inc.
www.myasd.com



On Sep 16, 2009, at 4:07 PM, Howard wrote:

> 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.
>
> --
> Posted By Howard to Tapestry Central at 9/16/2009 12:59:00 PM