I've got it set to single pass and I do have both a detail and summary report. However for the summary I do all of the grouping and counts in a SQL stored procedure and return just the summary records, which is very fast. I originally did the summarization in RSS but it was very slow. It would appear that even if you can query the data quickly it just takes RSS a substantial amount of time to process a large number of records even if they do not end up being printed.
-Larry
Since I found few performance issues on the RSS forum I decided to do a little testing. The BBS/BO that I'm using is mapped to a view and I select records by date range. The acutal loading of the BO is not an issue, just the rendering time. I ran another set of tests, one set with the SF BBS/BO and the same report and select criteria using an ADO Dataset. The query times were similar but the report rendering times showed a drastic improvement. It would appear that the SF BBS/BO adds additional overhead or there is some issue with RSS using it as a data source. For example 69K records took about 635 seconds to render using a BBS as the datasource but only 23 seconds using a Dataset. The only difference between the two sets of tests in the datasource.
I'm using SF v1.7.0.2. I'm no expert with ANTS memory profiler but I ran two profiles against the same report, one using a BBS and another using a dataset. I took memory snapshots after the data query (my baseline) and after the report finished rendering. What I found was that using the BBS in addition to being significantly slower uses a lot more memory. By the time the report was rendered, I had one instance of the BO for each record retrieved. This resulted in a memory increase of about 42 MB for the BO class. There was also a 45MB increase in the Stack<Delegate> class. For the BBS the number of bytes in all heaps increased from 50 to 213 MB and Private bytes went from 100MB to 270MB.
In contrast when using a dataset, the number of bytes in all heaps went from 78 to 108 and private bytes went from 123 to 163. It would appear that using a BBS is expensive in terms of memory but I'm not sure if this is the only thing impacting the total rendering time.
Am I the only one having performance issues rendering a large number of records? The BO I'm using for the BBS is very straight forward and doesn't contain any custom fields or scalar methods. I'm not sure if this is to be expected when using a BBS as a reporting source or if this is a problem that could be fixed. This would be a good point for Trent to jump in.