5. Report execution times are found in a table called ExecutionLog.  The time it takes to actually see the report on the desktop is about 5 seconds longer than the total of the times it keeps;  TimeDataRetrieval, TimeProcessing, and TimeRendering.  For this report these times add up to about 6 seconds less than it actually takes to see the report.  For smaller reports these times add up to about 3 seconds less than it actually takes to see the report.  By far the greatest of the three is TimeProcessing.  I haven't found any help on how to optimize anything based on these times - ie what causes longer processing time. 

The missing seconds would be the time it takes for the client to display the information. Nothing you do on the server will change that. This would be down to client hardware, software patches, display resolution, etc...

To reduce the TimeProcesing, do as much work as you can on the SQL side. EG: Instead of using an expression to join two fields together in a textbox, join the fields in the query. I've found that the more expressions and dynamic logic you put in the report the longer it will take to run.

6.I'm not sure what I'd be caching.  I should have enough memory on the machine to do all sorting in memory if it's all allocated right.

Reporting services will still use caching which is typical of a server application. This allows it to respond quicker to subsequent requests for the same information.

9.at least one smaller report that was imbedded in an intranet application was changed to asp report because it appears instantaneous to the user using ASP and takes 102 seconds using ReportingServices with link to report.

Presuming it's not already, I'd be interested in timings for this report done in ASP.NET instead of ASP. The extra delay could just be the overhead of the .Net framework.

From my use of Report Manager I've noticed that it can take 5-10 seconds to initially load and then, depending on the complexity of the report, an extra few seconds or for the first execution of the report.