Problem: Large lists of objects are iterated pointlessly for most uses of display tag. Except for on the first iteration, the CulumnTag methods do almost nothing if you specify the property for a column. Most of the time and empty cell is added toa Row and the Row added to the Table Model. However, adding a row to the table is unnecesary for most purposes, as we shall see. The typically unncessary iterations result in numerous method calls that dramatically hurt performance.
The sample paging jsp's only use a few columns--about 4. If you add a colum the number of additional method calls is multiplied by the number of rows for each column. Add 8 columns and a simple paging example that displays only 10 rows of a list of 2000 can take over 2 seconds of iteration time and then only 15-30 millis of real work in the TableTag doEndTag method. This makes the run time of display tag exponential. Solution: I wanted to skip the iterations and do only the work required. I was able to do this and get the time to nearly O(1), on non sorts. (There is still some iteration on building the partial list, so it is probably really O(N), but that iteration is negligible. Sorting is merge sort time. ) To do this I did a couple of things. 1. If the pageSize is greater than zero, I return SKIP_BODY from TableTag doAfterBody. I did it here to let the first colum iteration take place for building header. (The condition to skip should take into account more options, however.) 2. I pass the original list of data to TableModel. Then, if there is paging, in getViewable data of TableTag, I build up the rows of the TableModel that I want to use based on what is left of the orignal list after pulling out the chunk for the page. 3. If there is a sort, I made the RowSorter Implementation able to handle any object and not just a Row, so I can pass it the original list and not the Row wrapped list. This was easy. I just set object1 = obj1 (the method param). The ability to do this is key, since it makes the initial iteration largely unnecessary. Also, with the RowSorter enhancement, I was able to skip decoration for sorts. Another great boost. Result: With the plugable RowSorter enhancement and the runSimple changes I was able to sort without reflection. The total work takes about 16-30 millis for a list of 2000 items with 8 columns, whereas before it took 2 1/2 seconds. This makes display tag usable for very large result sets. I'm not sure what features will be unavailable with this enhancement. My proposed option should be configurable by setting a property like runSimple=true or something on the table. Also the condition to skip_body should take into account more that just whether or not the list can be paged. I may have left out a few details, but it works great for probably 99% of what anyone will do with the library. It should be an option to runSimple or something similar, since you can get a 200X performance boost at modest conditions. I'll submit patches if there are no obvious drawbacks. Cheers, Aaron Smuts http://jakarta.apache.org/turbine/jcs/ __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ displaytag-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/displaytag-devel
