One of the most simplest and effective ways to speed up your portal page loads is to leverage the Object Cache for MOSS, which comes as part of the product Out of the box. This settings can be modified in the SharePoint site : Site Actions > Modify All Site Settings > Object Cache Settings.
So what does this give you?
We all know that MOSS practically stores everything in its SQL database, so this could prove to be expensive from a networking perspective and can put heavy load on the SQL server, so this is where the object cache mechanism can take advantage on objects (Content) that are commonly requested. For example the Navigation control, most pages would have a navigation control embedded into a MOSS page, by storing these common objects to disk, will reduce the number of server hops required to be hit on the SQL Server decreasing page load time.
Sounds like a great way to speed up MOSS page loads.But when we get out of the arena of Out of the Box controls and jump into the land of customization, then the Object Cache settings can make or break the page load times. Confused?OK we need to dig a little deeper to get my point across.OK, let me give you an example; one of the ways to create a custom navigation control or a site map of your site structure would be to iterate through your sites and build up a control dynamically using something like the PortalSiteMapProvider class that is provided to you in the Microsoft.SharePoint.Publishing assembly.
Sounds about right. 
But what happens if you have something like 500+ subsites. I have seen companies having 5000 + subsites, but wait we would probably leveraging the Object Cache, as the PortalMapSiteProvider uses the CacheObject interfaces instead of the actual SPWeb objects.
But it still needs to build the cache the first time. If we look at the behavior of the PortalSiteMapProvider class, when we parse the map, a SPWeb object is cached for each node.
If let's say for arguments sake each node consumes about 1mb per node and our object cache size is only set to 100mb, if we have a large site structure and we come to the 101 node, the oldest object will be removed from the cache to allow for the latest node to be cached. If we had 500 nodes (sub-sites) only the latest 100 nodes will be cached and the remaining 400 nodes would have been stored in the cache and then removed making the object cache completely in-efficient, as the next request will have to rebuild all this again, causing really slow page loads and no benefit of the object cache, as what is now stored in the object cache is useless pile of muck. 
We will also fill up unnecessary memory causing w3wp.exe to run inefficiently. Also we end up with a high number of SPWeb objects being left open waiting for the most reliable [not] .Net Garbage Collector to free up its memory resource, because the objects are not disposed by design and if you are not careful with Verbose logging ramped up, you probably will end up with GB's of ULS logs in MOSS in minutes, eating valuable disk space, depending on your log settings.
So what can we do to improve this, well we have a few choices:
1. You can consider increasing the objects cache size, when it comes to a huge number of objects, start from 500MB, test and move up from there, tweaking the object cache size. Obviously, this will require your system to have an important RAM size, or will push you towards 64-bit if you are not already there.
2. Develop a navigation control to read an .xml file that can be updated through a custom windows or custom timer job, for example every 15mins. This type of solution does not provide a page to be visible until the xml file has been updated.
3. Develop your own provider, with another cache mechanism for instance caching the nodes and not the SPWeb objects.
The morale of this blog is when considering using the Object Cache; take into consideration the customization you may have implemented in your MOSS environment and the way the customization has been developed. If these considerations have not been considered and your development is leveraging the Object Cache interfaces you could have an adverse reaction to what you trying to achieve.
bobbyhabib