First, don’t do this. It’s never going to perform well. You have too many things that you’re asking the API to do. There are just too many operations.

Second, if you insist on doing it … Use CorasWorks. They’ve spent a lot of time and money dealing with performance issues like this one. They’ve got multi-threaded implementations that help performance (at least some.)

Third, did you see the first point? Seriously, consider restructuring how you do this. If you need to get documents uploaded in the last seven days, consider a service that runs and puts a reference to the documents in a database and have the web part read the database. You are likely going to find that this is the only way to get to sub-second response time.

The Report Pack for SPS could easily be extended to include information about documents. The source code is available: http://workspaces.gotdotnet.com/SPSReportPack

What about doing something with SharePoint Search.. Much like the "Recent Documents" on a users MySite. Do a search across all the sites and specify the date.

The webpart  tries to retreive not just documents but also Announcements and Events from the sites.
Yes, I tried convinsing the business guys that sharepoint email alerts is the best way for them to be notified when anyone adds/modifies stuff in the sites. But it came down to "Is it so difficult", "Should we contact Microsoft for support on this" - i did not know if i should laugh or cry for that. So I did a webpart and u guys know the rest of the story.

To solve this problem  I thought of using the Custom Alerts Channel route, but this works only on the Portal and not for the sites (I dont understand why they left out WSS from this feature).

Now to solve the webpart problem, I have implemented a Windows service which iterates through all the sites and gets the info and updates them to a List in the Portal homepage.
I then use good old ListViewWebPart to display the data.

I would probably write/run a nightly job that crawled the farm via the
API looking for the links that you want to present to the end user. I'd
put those links into a known SharePoint list (add, change, delete
style). Then I'd create a DVWP that simply presents the content of that
list via the Lists.asmx Web Service anywhere the user wanted to drop it.

Alternatively, you could conduct the crawl, asynchronously when the
first page of your SharePoint solution was visited each day generating
the list of links and placing the results into application cache, into
an XML file on the file system or in a document library, or even into
the Web Part's own cache. This way the list would be generated, without
the need for a nightly job, on first use and then stored for all
subsequent uses that day. The following day, the cache would be
refreshed.