On Thu, 15 Jul 2010 14:16:13 -0300, Pierce Wetter <pie...@paceap.com>
wrote:
Ok, this is all in the name of performance memory and otherwise,
There was a serious memory usage in applications with lots of pages and
many concurrent users.
You're completely changing the architecture to something you are
assuming will be faster,
This change wasn't aimed at speed.
but this new architecture seems like it will need lots of small tweaks.
I don't know if it will need, but tweaks can and will be made.
By the way, thanks for your insights.
So let me also propose the counter argument, which if I understand
correctly, that persistent fields already work that way, so really this
is extending regular fields to work the same way as persistent fields.
If that's true, then I'm only half right:
It's true. This change is way smaller than you're probably thinking.
Tapestry's code is almost as uncoupled and flexible as it's possible.
2. I was right: We should come up with some performance tests for
this. That might just be a matter of asking the guy who had been doing
Tapestry capacity testing to run his tests against trunk.
Howard said that in his blog post.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
