Tapestry so aggressively intermixes framework code and user code that it's going to be hard to pick it out. Futher, Tapestry's queue based (rather than tail recursive) approach makes it much harder to see what's going on. I would still advise you to use YourKit to measure across a long period of activity and look for the hot spots. And report them back here!
The abiding rule of performance is that after careful thought and analysis to identify where your problems are, profiling always points you to a completely different area that is your real problem. On Fri, Jan 16, 2009 at 11:44 AM, Fernando Padilla <f...@alum.mit.edu> wrote: > I'm using 5.1.0.0. > > But I'm sorry to confuse you all. I'm not trying to profile Tapestry > lowlevel code, I'm trying to profile my own component code :) > > I want to know collectively how long any one of my component takes to > render. The reason I think this view of things would be useful, is that > profiling at method level might not give me a clear picture of where to > focus on.. ( we'll see lots of setupRenders. lots of beginRenders, but no > relationship between one component and how it depends on subcomponents, etc > etc) > > Do you understand? So it's not profiling Tapestry code precisely, but > profiling pages/components via the view of tapestry's component rendering > tree.. > > I don't know if it would be ultimately useful, but it sounds like an > interesting idea.. > > > Howard Lewis Ship wrote: >> >> Are you using Tapestry 5.0.18 or 5.1.0.0-SNAPSHOT? I've added some >> considerable performance improvements to 5.1. >> >> I would get a copy of YourKit and start profiling to see where the >> actual problems are. >> >> Tapestry takes a hit because it renders the entire document to a kind >> of light-weight DOM before it can start to stream the output; that's a >> lot of churn in the JVM's eden heap space. >> >> On Thu, Jan 15, 2009 at 8:17 PM, Thiago H. de Paula Figueiredo >> <thiag...@gmail.com> wrote: >>> >>> Em Thu, 15 Jan 2009 23:19:56 -0300, Fernando Padilla <f...@alum.mit.edu> >>> escreveu: >>> >>>> The database was just upgraded and io/cpu is really really low. So that >>>> won't be the case. >>> >>> I would still check this out . . . Don't forget about one transaction >>> waiting for others to release locks in table rows . . . >>> >>>> The root cause might be the number of db requests required to render a >>>> page, but the database it self is not the bottle neck. :) :) >>> >>> A real case I found as a consultant was the lack of attention to >>> Hibernate >>> mapping options, specially regarding lazy loading of collections. Instead >>> of >>> using one or two selects to load an entity object and one of its lists, >>> it >>> was using one for each element in the list. This absolutely kills >>> performance. >>> >>> By the way, nice performance improvement hunting! :) Don't forget to >>> share >>> your experience with us. ;) >>> >>> -- >>> Thiago H. de Paula Figueiredo >>> Independent Java consultant, developer, and instructor >>> http://www.arsmachina.com.br/thiago >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: users-h...@tapestry.apache.org >>> >>> >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
