FWIW, I've noticed largely the opposite - Xcode uses less memory (currently sitting at 32 meg with one project open), Mail uses a *lot* less - it used to suck up over 100 meg under 10.3 when browsing through large mailboxes (20k items)... currently sitting at 27 meg under Tiger.
I see mostly the same thing, significantly decreased Xcode and IB memory usage (only 27 and 13 MB respectively with one project open) although I think Mail's usage is more dependent on how many messages you've viewed since you've opened the app. That's my experience anyway.
Safari of course sucks up as much memory as it can, plus 100 meg. It's like that on any system. Try a different browser. This isn't a flame against Safari, which I use as my primary browser anyway, just a sad statement of fact. Firefox isn't usually much better - Camino was way smaller and faster, but of course is showing it's age these days.
I don't see that with Safari so much. Yeah it takes a lot, but not like OmniWeb with an egregious 406 MB. One thing I have noticed though, is that if you run Safari for a few days without closing it, it's CPU usage will go through the roof. I've only seen it twice though, and before I reinstalled Tiger (my first install was faulty), but I haven't left it open long enough to test since then.
To bring this back on topic, however, I'd like the pose the query - has anyone tested their programs to see exactly when autorelease pools are actually released? I sometimes wonder about Cocoa apps which use a lot of memory for a task, and then don't seem to release it again (e.g. Safari) until they're quit. I suspect a more liberal use of localised autorelease pools would do wonders. But I've never tested this, since I don't develop programs which are susceptible to such problems. Anyone out there with a large Cocoa app that can shed some [empirical] light on this?
I've done a bit of testing (debugging one app, really) on this subject. One answer is: never during a for or while loop. You need a local autorelease pool that gets alloc'd and released every (few) iteration(s) if you want to use methods that create autoreleased objects, especially more than one; -subdataWithRange: and -substringWithRange: come to mind as the worst offenders. The overhead of creating and destroying an autorelease pool, even every iteration, slows down the program only a tiny fraction of the amount that consuming all that memory for the autoreleased objects does.
-Dan