YOu could test the stored procedures by running them in Query Analyzer. If they are still slow, the stored procedure needs to be fixed. Otherwise the problem could be in the connection to the database or the reports. Some things to think about in terms of increasing speed.
Good indexes on the tables/views can speed up a query in a table that has a lot of records.
Avoid cursors, they are notoriously slow. Usually they can be replaced by set oriented SQL statements once the programmer gets over thinking in procedural terms.
SQL statements that are called from the usesr interface without using a stored porocedure are slower.
Don't ask to return more results than you need. This slows up the system by clogging it with more data packets than necessary. It doesn't seem like much when it is one user, but, you get into a big multiuser enviroment and these things add up.
Check to see how busy the network is, sometimes other network traffic is what is slowing you down. This is always most noticible in a database environment because databses make frequent calls through the network to the data, where as other applications like word processors are only slow when they save. I once worked in a place with a network designed for 200 people that actually had 400 people. They kept complaining the database was slow, but itwas really the network.
