Mailbox very slow with direct login but ok when proxying

Question

We have a large common departmental account monitored by multiple users (yes, shared account, not shared folder). When I log in directly to the account and select a folder it can take 10-15 secs to populate the list of items. Seems to apply to nearly every folder, even those with small numbers of contents (5-30 items), not just those with many items. If I log into my own account and proxy to the shared account then the folders also get populated fairly quickly (0.5-2sec). No problem with my own folders so sounds like its specific to the other account.
Connections are c/s only. C/s handler threads spend most of their time 0 busy with occasional bursts of activity that clear again
Message handler and soap threads seem to remain at 0 all the time
C/s requests pending remains at 0.
Problem occurs running client on XP and on Windows 7 64bit.
Have run GWCHECK to fix a few probs but problem continues. Appears to be just a problem with this one account but the key point is why the difference between direct logged-in and proxied?

Answer 1

No I'm not particularly bothered about the LOGIN time, that only happens once. The problem is the time to browse between different folders once login is complete. (sorry for the confusion, I 'll edit the OP to make it clearer).
Good:
Login as self, proxy to uber-account, wait for completion. Then click on a random folder, wait for message list to be populated (network traffic completed <1s), GUI updated <1 sec, maybe 2secs if many messages in list. Same acceptable performance occurs when clicking on subsequent folders. Workstation CPU usage during update 1-2%.
Bad:
Login as uber-account, wait for completion. Click on a random folder, wait for message list to be populated (network traffic completed <1s), GUI not updated for 10-15secs - all of the items refreshed together at the end of the period so to the user it looks like you've clicked on a new folder and the contents is the same as the previous until it suddenly refreshes after 10secs. Same problem occurs when clicking on subsequent folders. Workstation CPU usage during update 50% (dual core in this example, so probably maxing out one core for 10 secs).
No significant disk activity during update period. No significant network tfc after initial burst. Memory ok. No change of performance when anti-virus disabled. Same behaviour on other machines so not just one baddy. My money is it's something to do with the number of folders, or the number of shared folders owned by the uber-user, or a corruption the normal GWCHECKs aren't dealing with.
Joe