DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15041>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15041 Add totals to Aggregate Report ------- Additional Comments From [EMAIL PROTECTED] 2002-12-10 09:15 ------- The attached patch makes the following changes to the aggregate report: - Added a "TOTAL" line to the report. - Changed the "rate" column to represent physical pages per unit of time -- instead of some theoretical value that nobody understood. This has the additional advantage of being much cheaper to compute (no need to track which threads generated the samples anymore). - Improved performance of the report by avoiding unnecessary information copying (as per Swing's TableModel recommendations) and firing table changed events for only the rows that have actually changed. Some other minor performance improvements by avoiding unnecessary hash lookups -- one is saved by holding a RunningSample's order in the table in an index field in the RunningSample itself, the other one by avoiding a hashmap.containsKey immediately followed by a hashmap.get. - Solved a minor bug in getMin and getMax (were returning nonsense for a just-created RunningSample). - Correctly internationalized the Aggregate Report component name. - Corrected at least one race condition in which if two threads 'simultaneously' reported a sample which was not yet in the table, you could end up loosing one of the samples. There may be other similar issues solved, because I was generally carefull with synchronization, which didn't seem to be the case in the earlier code. Performance test resuts: - I ran a very simple script creating 3 rows in the table: one changing slowly, one changing as rapidly as possible, and the totals. I got over 15500 requests in 1 minute, where I was getting just 14200 with the old code (which didn't have the burden of computing and refreshing the totals line). I expect the difference to be *much* bigger as the size of the table grows. Remaining issues: - Table sorting still not implemented. - Would like to represent the totals in a different background or in bold font. - I feel the StatVisualizerModel should return the results in numeric form and the Visualizer itself should be all the formatting. It's not currently done this way. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
