SR-Sorry, thought white papers (TBMM link) might serve for increasing the knowledge pool. With your numbers, I would have to agree that FastMM is bomb (4.97) and XP is broken. Still, your ThreadHeap2 does make for smoother game-play...at least on my machine.
No.... wait, wait, it's good.
FastMM4 outperformed (barely for Oblivion purposes, significantly for typical purposes) all other heaps I had tested. But I noticed that TBBs heap comes readily available as a separate dll that's just as easy to use as BorlndMM.dll and tried using it in OSR, and it's fast. I haven't done any test runs in Oblivion itself yet (that takes more time & effort and is less reproducible) where the really complex loads are, but for both low and medium complexity benchmarks I tried it was across the board significantly faster than all other heaps I've tested (I should update to a more recent FastMM to make things fairer, but still, TBBMMs performance on my synthetic tests is awesome). Of course, in Oblivion going faster than SimpleHeap1 doesn't produce much additional benefit. Even if it's not fast in Oblivion it's an extra heap option that doesn't require any extra work on my part, so if people encounter instability on of the other heaps OSR supports there will be one more option. And likely it will be very fast in Oblivion.
The next WIP will add support for
TBMM TBBMM.
Mind you, I still think his test methodology svcked in that article or whitepaper or blog post or whatever

Fast MM 4.97
Quote:
...is not prone to memory fragmentation...
Resistant to address space fragmentation
Zach Saw and TBBMM:
I think some ideas from Zack Saw were implemented into FastMM 4.97
Quote: Added the UseSwitchToThread option. Set this option to call SwitchToThread instead of sitting in a "busy waiting" loop when a thread contention occurs. This is used in conjunction with the NeverSleepOnThreadContention option, and has no effect unless NeverSleepOnThreadContention is also defined. This option may improve performance with many CPU cores and/or threads of different priorities. Note that the SwitchToThread API call is only available on Windows 2000 and later. (Thanks to Zach Saw.)
I think TBBMM is based on parts of this: http://www.threadingbuildingblocks.org/
... but my game is more stable with threadheap2
Bizarrely enough, that it is resistant to memory fragmentation issues does not, in that context, necessarily imply that it is resistant to address space fragmentation. Despite the fact that both refer to logical addresses only. For instance, Oblivions vanilla heap is considered low-fragmentation (it has to be, since they run on consoles), but it is high fragmentation with regards to the address space left over after its footprint is taken in to account.
So it doesn't immediately try allocating a GB of memory @ 1024? I figured if modes 3 and 5 were set at a fixed size, they had to be that large from the beginning. After I changed it back to 1024 and it was stable again, I checked in the Resource Monitor and Oblivion.exe had in the Commit ~1,455,000KB, Working Set was ~500,000KB and Private was ~500,000KB ...
If I try iHeapSize @ 450, low enough to make sure I can see the difference in Resource Monitor, the Commit is ~850,000KB, Working Set and Private Set are both slightly smaller around ~400,000KB. So it at least seems for me the iHeapSize is making Oblivion.exe want more memory the higher it goes, and maybe my instability had something to do with the the "Free" vs "Cached" RAM.
I can test it again if I wanted, I just need to stay logged in long enough until there is <1500 "Free" in memory and most of it is "Cached", and see if iHeapSize @ 1024 becomes unstable.
OSR does immediately allocate a GB @ 1024. But weren't you the guy who had 12 GB of physical memory? And that's not even counting virtual memory (though I suspect Oblivion would crash if it started swapping much). That's not going to be a limiting factor for Oblivion. Though... address space shouldn't be either, not when LAA is enabled. I don't know.
jonwd7, would your problems with stutter/freezing maybe have to do with HDD and the background loader? Especially the Shadowmere riding. Seems to me that nothing short of SSD would allow for seamless loading of forward grids, and that is still asking for miracles.
andalaybay, have you tried the following:
Open Streamline ini (data/Streamline/INI Files/sl.ini) turn off reminders, turn off the bell sound, turn off save after battle, basically just leave Save When Idle on with Secure Save. Save ini try again.
Also, just to be sure, check your Oblivion.ini file for:
bSaveOnInteriorExteriorSwitch=
bSaveOnRest=
bSaveOnTravel=
bSaveOnWait=
set all the above to "0" then find:
bAllowScriptedAutosave= set to "1"
OSR w/ heap replacement enabled and no LOD mods gets pretty close to seamless loading of grids on my (several year old) computer which has no SSD. And even with LOD mods I can get back to that by following Arthmoors suggested oblivion.ini tweak.