You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Cherry Development <av...@cherrydev.com> on 2004/04/20 07:52:15 UTC
Tapestry Architecture - Page and object pooling
http://www-106.ibm.com/developerworks/java/library/j-jtp01274.html
I've in the past sent a few questions to this mailing list speaking
about the page pooling mechanisms that are currently in use in
Tapestry, particularly in comparison to the approach offered in
WebObjects. I found the above article very, very interesting. The
main point of it is that in a modern JVM, the costs of allocating a new
object (such as a tapestry page) are much lower than they used to and
that object pooling techniques are probably a net performance penalty
at this point.
I'm hoping to spark some discussion about this. Perhaps there are
parts of the architecture of Tapestry that are based on old assumptions
about Java's performance and are doing more harm than good,
particularly in the case of application design.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Tapestry Architecture - Page and object pooling
Posted by Programozás <pr...@hotmail.com>.
This would be good news because we won't need database connection pools
anymore for example :)
Maybe my last writing about this was too long and nobody has read it: this
WebObject-like behaviour is almost possible with 3.0 (few framework classes
neeed to be modified) and will be possible with 3.1 if the enhancement bugs
will be fixed.
N.
----- Original Message -----
From: "Cherry Development" <av...@cherrydev.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Tuesday, April 20, 2004 7:52 AM
Subject: Tapestry Architecture - Page and object pooling
> http://www-106.ibm.com/developerworks/java/library/j-jtp01274.html
>
> I've in the past sent a few questions to this mailing list speaking
> about the page pooling mechanisms that are currently in use in
> Tapestry, particularly in comparison to the approach offered in
> WebObjects. I found the above article very, very interesting. The
> main point of it is that in a modern JVM, the costs of allocating a new
> object (such as a tapestry page) are much lower than they used to and
> that object pooling techniques are probably a net performance penalty
> at this point.
>
> I'm hoping to spark some discussion about this. Perhaps there are
> parts of the architecture of Tapestry that are based on old assumptions
> about Java's performance and are doing more harm than good,
> particularly in the case of application design.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Tapestry Architecture - Page and object pooling
Posted by Jonathan Locke <jo...@muppetlabs.com>.
i agree with the overall argument that pooling can be necessary because
object construction can be expensive.
however, i don't agree that pooling heavyweight page instances is the
only or even the best way to solve the problem at hand.
as i was saying earlier, it ought to be possible to refactor pages so
that just the heavyweight part is pooled (or even static/unsynchronized).
it's possible that this could give tapestry a more intuitive object
model (which means less learning curve and more developer productivity)
AND while still solving the page construction performance problem.
Howard M. Lewis Ship wrote:
>The page must be allocated using reflection.
>
>Every compononent on the page must be allocated using reflection.
>
>All the relationships, bindings, template objects and etc. must be wired together for the page and
>for each component within the page.
>
>Many optimizations occur when a page *first* renders that would be lost if we created the entire
>tree every time.
>
>On top of that: the <property-specification> element ensures that the very problems you are
>concerned with are accounted for.
>
>You are missing a lot of the history: Tapestry used to aggressively pool lots of small objects
>(HashMaps, StringBuffers, object arrays). I read the same articles as you ... I did some performance
>testing, and I pulled the pooling out for everything but pages.
>
>
>--
>Howard M. Lewis Ship
>Independent J2EE / Open-Source Java Consultant
>Creator, Tapestry: Java Web Components
>Creator, HiveMind
>http://howardlewisship.com
>
>
>
>
>>-----Original Message-----
>>From: Cherry Development [mailto:avi@cherrydev.com]
>>Sent: Tuesday, April 20, 2004 1:52 AM
>>To: Tapestry users
>>Subject: Tapestry Architecture - Page and object pooling
>>
>>
>>http://www-106.ibm.com/developerworks/java/library/j-jtp01274.html
>>
>>I've in the past sent a few questions to this mailing list speaking
>>about the page pooling mechanisms that are currently in use in
>>Tapestry, particularly in comparison to the approach offered in
>>WebObjects. I found the above article very, very interesting. The
>>main point of it is that in a modern JVM, the costs of
>>allocating a new
>>object (such as a tapestry page) are much lower than they used to and
>>that object pooling techniques are probably a net performance penalty
>>at this point.
>>
>>I'm hoping to spark some discussion about this. Perhaps there are
>>parts of the architecture of Tapestry that are based on old
>>assumptions
>>about Java's performance and are doing more harm than good,
>>particularly in the case of application design.
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Tapestry Architecture - Page and object pooling
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
The page must be allocated using reflection.
Every compononent on the page must be allocated using reflection.
All the relationships, bindings, template objects and etc. must be wired together for the page and
for each component within the page.
Many optimizations occur when a page *first* renders that would be lost if we created the entire
tree every time.
On top of that: the <property-specification> element ensures that the very problems you are
concerned with are accounted for.
You are missing a lot of the history: Tapestry used to aggressively pool lots of small objects
(HashMaps, StringBuffers, object arrays). I read the same articles as you ... I did some performance
testing, and I pulled the pooling out for everything but pages.
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Tapestry: Java Web Components
Creator, HiveMind
http://howardlewisship.com
> -----Original Message-----
> From: Cherry Development [mailto:avi@cherrydev.com]
> Sent: Tuesday, April 20, 2004 1:52 AM
> To: Tapestry users
> Subject: Tapestry Architecture - Page and object pooling
>
>
> http://www-106.ibm.com/developerworks/java/library/j-jtp01274.html
>
> I've in the past sent a few questions to this mailing list speaking
> about the page pooling mechanisms that are currently in use in
> Tapestry, particularly in comparison to the approach offered in
> WebObjects. I found the above article very, very interesting. The
> main point of it is that in a modern JVM, the costs of
> allocating a new
> object (such as a tapestry page) are much lower than they used to and
> that object pooling techniques are probably a net performance penalty
> at this point.
>
> I'm hoping to spark some discussion about this. Perhaps there are
> parts of the architecture of Tapestry that are based on old
> assumptions
> about Java's performance and are doing more harm than good,
> particularly in the case of application design.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org