Tapestry 5 performance has been really good, for the trival demo apps I've put together so far.
Tapestry 4 could probably be optimized a bit more; for example, it uses a lot of StringBuffers which are pretty slow. The overhead of the DOM is not so great, and there will be a lot of room to optimize. It's pretty streamlined compared to, say, Dom4J. It also makes things a lot easier to code since you can randomly access any node in the tree. This simplifies the complex relationship between Label and TextField; the Label can wait unti after the TextField renders in order to determine the correct value for its @for attribute. Most requests are taking under 4ms, and that includes the time to check for invalidated files (in production, that check will occur less often). Code is coming together on it, but there's so much more to do, including localization, assets, JavaScript support, the rest of the form components client- and server-side validation, invisible instrumentation, etc. On 11/7/06, Vinicius Carvalho <[EMAIL PROTECTED]> wrote:
Hello there! It's been a while since my last post, I tried to catch up, but after reading over 500 topics I gave up ;). I was checking Tapestry 5 site (Wow it changed so much that I could not even recognize it as Tapestry ;) ). One thing that intrigues me is the use of DOM from the MarkupWriter. Wouldn't it degrade performance? Regards -- IBM Certified SOA Solution Designer IBM Certified Database Associate - DB2 V8.1 Family Sun Certified Enterprise Architect (Part I)
-- Howard M. Lewis Ship TWD Consulting, Inc. Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache Tapestry Creator, Apache HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com
