Fabrizio did you get a chance to look at my patch I submitted last week?
-David
 
----- Original Message -----
Sent: Monday, June 21, 2004 3:12 PM
Subject: R: [displaytag-devel] Fwd: Display Tag Performance Enhancements

Great, I will look at his changes in the next days and commit it they look good...
 
there are some thing that surely are needed, like arraylist presizing, but I'm not sure about the use of other "cached" methods. For example the hasGetterFor() method is already cached in latest releases, I'm pretty surprised it can be so slow (maybe I can try to fix it instead of adding another cache)
About the caching of the open column tag string... it actually can work if we assume that column attributes can't change from row to row, but in future we will probably need to allow changing attributes dinamically (see http://sourceforge.net/tracker/index.php?func=detail&aid=949187&group_id=73068&atid=536613 )
 
thanks for your work, todd
fabrizio


Da: Matt Raible
Inviato: lun 6/21/2004 4:58
A: [EMAIL PROTECTED]
Oggetto: [displaytag-devel] Fwd: Display Tag Performance Enhancements

Anyone care to review and commit these?  I don't have the bandwidth 
right now.

Matt

Begin forwarded message:

> From: "Benge, Todd" <[EMAIL PROTECTED]>
> Date: June 21, 2004 10:51:29 AM MDT
> To: <[EMAIL PROTECTED]>
> Subject: Display Tag Performance Enhancements
>
> Hi Matt,
>
>  
>
> My name is Todd Benge.  I’m the technical lead on a software project 
> at Level 3 Communications.  We’ve been using the display tag for 
> roughly six months now for a number inventory system.  We’ve found the 
> feature set very rich and would like to thank you for the good 
> product.   The volume on our system has grown exponentially in the 
> last few months and thus we began to notice a significant performance 
> issue on our production servers.  It’s not uncommon for our users to 
> display and work with very large sets of tables – i.e. 5,000 to 10,000 
> rows.  When profiling our performance problems, we noticed a 
> significant amount of the CPU time was spent processing in the 
> displaytag libraries, especially after to the upgrade to the 1.0 rc1 
> release.  There are several steps we are taking to improve the overall 
> system performance, one of which was to look at the displaytag source 
> code.  In doing so, we were able to make a couple of significant 
> changes that have made a major impact on overall performance.  So far 
> the changes we’ve made have not had any impact on functionality but we 
> do not use the el tags or velocity templates.  We’ve tagged all of the 
> changes in the source files with my name (Todd) so that you can 
> evaluate the changes.  The attached jar file includes the source files 
> changed as well as the Borland Optimizeit profiles taken before and 
> after the work was completed.  You should see that the processing time 
> spent in the tag libraries and main JSP is significantly reduced.  
> This is mostly due to caching of previously reflected methods and the 
> removal of the iteration in the doAfterBody of the TableTag.  If the 
> changes look reasonable, we’d be happy to commit the changes back to 
> the community.  The two authors of the changes are Todd Benge and Matt 
> Green.
>
>  
>
> Just a side note, when I was looking for your email address I noticed 
> you are originally from Bozeman, MT.  I’m originally from Miles City, 
> MT and went to school for my BS degree at Montana State.
>
>  
>
>  
>
> Please feel free to contact me if you have any questions.
>
>  
>
> Thanks,
>
>  
>
> Todd

Reply via email to