It would also be interesting to know what you row count and byte sizes are for the reports that are taking a while.  And how do these stack up against a report like the sample 'Territory Sales Drilldown'.  On my machine, this report returns all of the ~2600 rows to the client (prob report property set to 'fit on single page if possible' mixed with the groupings, anyway, i can't make it page).  It's about 17.5 kb in size, takes <1 sec to retrieve, process and render (all logged times) yet it takes longer than this to present to the client (IE).  I'd have to agree with Phil that a lot of this will be limited by the browsers ability to render the html (and probably a heavy amount of jscript).  For whatever reason, the expansion and contraction of the groups is not a fully client side event, it does a postback (of sorts) to the server - most likely so that RS can pickup the event happening and action it (if you set something to happen on open/close of the grouping). A quick test on my laptop shows my IE spiking to ~15% CPU for each and every click on the +/-, this is also definitely a round-trip event as the asp worker processes gets some processor time also.  I tried mucking around with setting the support for Javascript in the device settings (for HTML3.1 and 4.0 'devices') but it doesn't seem to make that much difference.

Just out of interest, what's the display time like when executing the reports in IE on the server itself?