[RELz] Oblivion Stutter Remover (OSR)

Post » Wed Mar 09, 2011 5:45 am

There seem to be a little of issues lately with iHeapSize. Possibly I should change the default heap algorithm to 1? It went back and forth a few times a long time ago, but eventually I concluded that comparable numbers of people had problems with each heap algorithm.

And you really shouldn't be having this sort of problem with LAA enabled, especially on a mostly unmodded game. Or at least, I don't think you should. You've got 4 GB of address space. Oblivion.exe only takes up a tiny fraction. DLLs shouldn't take much, in and of themselves anyway. I don't know how or where windows heap takes any (windows heap gets used regardless of anything else - OSR uses it internally, Oblivion uses it in many places even when OSR heap replacement is enabled, probably OBSE and OBGE use it as well), but it can't be all that big on a lightly modded game. OSR heap replacement removes Oblivions heaps small but highly fragmented footprint. What else can there be? Maybe you should ask the OBGEv2 guy (Scanti, I believe) if he's doing anything to use up or fragment address space?
User avatar
Lily
 
Posts: 3357
Joined: Mon Aug 28, 2006 10:32 am

Post » Wed Mar 09, 2011 2:34 am

I'm certainly not a Windows memory management expert, but if you have 7000+ cached, and 1500 "free" don't you really have 8500+ "free"? I checked how much was "free" and it was around 1500. I logged off, tried it on 1024 and didn't crash. *sigh*

But according to Resource Monitor even though 7000 is "cached" right now and 3155 is free, I only have 17% of my physical memory used. So who knows how the hell logging off and back on made Oblivion stable again... (maybe you do :))

Is it possible the heap can only deal with what is completely free? Again, not a Windows memory management expert here. haha.
User avatar
Jaki Birch
 
Posts: 3379
Joined: Fri Jan 26, 2007 3:16 am

Post » Wed Mar 09, 2011 11:36 am

It's a matter of address space, not physical memory. Oblivion gets exactly 2 GB (no matter what your hardware is) without LAA, or exactly 4 GB with LAA. Only things pertaining to Oblivion.exe use up any.

And, my heap implementations, like many, can only deal with contiguous (aka unfragmented) address space. Oblivions native heap can deal with somewhat fragmented address space, though it has a nasty habit of fragmenting any leftover address space more than it should. I not entirely sure what FastMM4 does, but I believe it at least prefers contiguous address space. I have no clue what Microsofts heap implementation does. I'm not even sure that all the dlls are using the same MS heap... possibly multiple independent MS heaps are being set up somehow, though I doubt it.
User avatar
lolly13
 
Posts: 3349
Joined: Tue Jul 25, 2006 11:36 am

Post » Wed Mar 09, 2011 3:09 am

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
User avatar
James Potter
 
Posts: 3418
Joined: Sat Jul 07, 2007 11:40 am

Post » Wed Mar 09, 2011 5:52 am

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


Has anyone found a replacement DLL with the actual version 4.97 somewhere? Any download from http://sourceforge.net/projects/fastmm/files/FastMM%204.x%20Stable%20Releases/ that has a higher version number than 4.76 actually still contains version 4.76, at least for the replacement DLLs. So, unless I miss something, there is no way to get a higher version than 4.76 as DLL, as even the sources for those DLLs share the same CRC in all files that I tried.
User avatar
Genevieve
 
Posts: 3424
Joined: Sun Aug 13, 2006 4:22 pm

Post » Wed Mar 09, 2011 6:44 am

Has anyone found a replacement DLL with the actual version 4.97 somewhere? Any download from http://sourceforge.net/projects/fastmm/files/FastMM%204.x%20Stable%20Releases/ that has a higher version number than 4.76 actually still contains version 4.76, at least for the replacement DLLs. So, unless I miss something, there is no way to get a higher version than 4.76 as DLL, as even the sources for those DLLs share the same CRC in all files that I tried.


http://www.4shared.com/file/JwFc0ebh/BorlndMM.html
User avatar
Julie Ann
 
Posts: 3383
Joined: Thu Aug 23, 2007 5:17 am

Post » Wed Mar 09, 2011 1:03 am

It's a matter of address space, not physical memory. Oblivion gets exactly 2 GB (no matter what your hardware is) without LAA, or exactly 4 GB with LAA. Only things pertaining to Oblivion.exe use up any.


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.
User avatar
aisha jamil
 
Posts: 3436
Joined: Sun Jul 02, 2006 11:54 am

Post » Wed Mar 09, 2011 9:08 am

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"
User avatar
Sabrina Steige
 
Posts: 3396
Joined: Mon Aug 20, 2007 9:51 pm

Post » Wed Mar 09, 2011 9:38 am

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.
User avatar
Smokey
 
Posts: 3378
Joined: Mon May 07, 2007 11:35 pm

Post » Wed Mar 09, 2011 6:12 am

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"

I assume you switched our names around. I was like, "Huh?". :)

Like I said in the last few posts, I logged off and logged back in to clear some memory and it started working just fine on the save file that had reproducible crashing before. I had noticed that Windows had ~1500MB of memory "Free" and 7000+ "Cached" but I figured with heap replacement Oblivion could be taking up more than what was "Free" even though "Cached" counts as free memory because it can be cleared. After logging back in "Free" was at 3500MB and I didn't crash.

Like I said in the last post, I also compared the memory footprint of Oblivion.exe with iHeapSize @ 1024 and @ 450, and they were about:

1024: Commit = ~1,455,000, Working Set = ~500,000, Private = ~500,000
450: Commit = ~860,000, Working Set = ~425,000, Private = ~425,000

And these were both after just loading the save with the reproducible error, trying to crash it by fast travelling, and then alt-tabbing out to view the memory footprint. I'm waiting to see what SkyRanger has to say about this though, because he said it wasn't a RAM issue. *shrug*

And like I said above, I'm waiting for my computer to be on long enough where "Free" RAM gets under 1500MB, and then try to see if it's unstable again. I can't imagine what else would fix the iHeapSize of 1024 by logging off and back on other than memory...
User avatar
tegan fiamengo
 
Posts: 3455
Joined: Mon Jan 29, 2007 9:53 am

Post » Wed Mar 09, 2011 10:48 am

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 :P

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.
User avatar
Trish
 
Posts: 3332
Joined: Fri Feb 23, 2007 9:00 am

Post » Wed Mar 09, 2011 10:26 am

...
The next WIP will add support for TBMM.
Mind you, I still think his test methodology svcked in that article or whitepaper or blog post or whatever :)
...

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.



Yeah, I do have a ton of RAM, but my theory was that since Windows considered nearly 8GB of it tied up in "Cached" RAM, with only 1.5GB actually "Free" that this was causing the instability at iHeapsize = 1024. The theory was that for whatever reason it's not deallocating some of the cached RAM for use by Oblivion. Because Oblivion starts out at 1.5GB immediately with iHeapsize 1024. It was then stable when the "Free" RAM reported was >3GB.

I know how UNIX works in regards to "Cached" vs "Free", but maybe Windows doesn't like letting go of Cached memory.

TBBMM (make sure you remember the extra "B" :)) sounds awesome. I like anything that uses Intel's TBB. :)

Isn't FastMM one of the most stable heap modes? I wonder if this carries over to TBBMM, then. And plus this gets rid of the need for worrying about iHeapSize, if I try out TBBMM, unless you have to institute a static heap size for TBBMM of course. It would be nice to have a heap mode that both scales for multiple cores and can resize itself.
User avatar
Liii BLATES
 
Posts: 3423
Joined: Tue Aug 22, 2006 10:41 am

Post » Wed Mar 09, 2011 12:23 am

SR-Good! I was hoping I wasn't just fantasizing. So very glad if it gets us more out of Oblivion...

"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." Arthmoor, where are you and what tweak is SR refering to in Oblivion.ini for LOD?
User avatar
Bek Rideout
 
Posts: 3401
Joined: Fri Mar 02, 2007 7:00 pm

Post » Wed Mar 09, 2011 12:59 am

...
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.
...


Both lines are quotations, the first is from the description part and the second from the advantages part. My knowledge is too small for such statements. Description and advantages, line 4 - 33 http://fastmm.svn.sourceforge.net/viewvc/fastmm/FastMM4.pas?revision=29&view=markup
User avatar
Jon O
 
Posts: 3270
Joined: Wed Nov 28, 2007 9:48 pm

Post » Wed Mar 09, 2011 7:32 am

I don't think I've ever actually gotten far enough in the DB questline to see or ride shadowmere. I'm assuming this is a very fast horse? If you're using LOD mods and have not tried reducing your uGridsDistantCount or whatever you might try that. But generally OSR already does a lot to improve the stutter that accompanies high speed exterior travel. Shadowmere has some graphic effects IIRC, but you implied that it gets better when you take your hand off the keyboard for a few seconds though, so it sounds like an exterior travel issue not a graphics issue though.

I've heard a few reports of stuttering in large fights (particularly against NPCs, not monsters) but have not seen it myself (well, I've seen low FPS on fights when using bad graphics cards, but I don't think that's what you're talking about). I don't really know anything about any code likely to be involved in that. If you send me a log of a session with lots of this stutter with CS profiling enabled and maybe Master/bExtraProfiling too I might be able to... well, I probably couldn't do anything. If there happened to be a CS involved in a big way I might be able to suggest a tweak or two. If there was something particularly interesting showing up in the ExtraProfiling data I might be able to get a hint what code was involved. It would help if I could produce such problems locally.

Oh, and did you change OSR ini settings? Particularly the CriticalSections stuff, the critical section overrides, and iThreadsFixedToCPUs? If you have iThreadsFixedToCPUs set to a higher value, try lowering it to 1 or 0. Probably 0. If you changed CriticalSections/iDefaultMode to say 6 or 1 or something, try changing it back to 2.

...snipped...


Yeah, Shadowmere is a black horse, so she's pretty quick. I haven't touched the uGridstoLoad - it's still set to the default of 5. My version of Shadowmere doesn't have any graphic effects - I loaded Slof's horses and didn't go for any of the extra options. Fights with NPC's are difficult even with just 3 or 4 of them because of the stutter/freezing.

My graphics card is pretty good (Nvidia GTX 285 - 1 GB Dram). I can enable some of those profiling options and send the log along.

I haven't changed the ini other than enabled heap replacement and setting the fps cap to 60. I did try enabling the experimental settings, but when that didn't improve things, I disabled them again. When I had them enabled, I changed the settings as follows:
	iReduceLongSleep = 2	bRemoveShortSleep = 0	iThreadsFixedToCPUs = 2


But as I said, I've set bExperimentalStuff to 0, so these settings don't matter anymore, correct? Should I try enabling them with the iThreadsFixedtoCpus that you suggested?

I'll send the log along when I do another long run along the roads.

Thanks for your help!

Edit: If you can get OSR FastMM4 working with TBBMM, I'd be interested in trying that. As I said, I've switched to FastMM4 because at least I'm not getting the long freezes with it. Maybe there's no need to mess with the logs - maybe just try the new OSR if you get the new memory manager working - what do you think?
User avatar
Christine
 
Posts: 3442
Joined: Thu Dec 14, 2006 12:52 am

Post » Wed Mar 09, 2011 7:02 am

andalaybay:
Try lowering uGridDistantCount and uGridDistantTreeRange. To, like, 15 maybe. Maybe lower if necessary. Note that those are not uGridsToLoad - IIRC you should never change uGridsToLoad under any circumstances.

moto:
I was refering to uGridDistantCount.

jonwd7:
Isn't FastMM one of the most stable heap modes?
Not that I know of. So far as I know, they're all about equal, just Oblivion dislikes some on some computers at random. Though FastMM (unlikey my heap algorithms) is willing to resize itself at runtime, which does help some issues.

Baphometal:
To be fair, Oblivion's heap is something of an oddity in that regard. Normally I suspect most low fragmentation heap managers won't really fragment address space much. But when a heap talk about low fragmentation it's generally talking about memory inside the heap, not the overall address space the heap itself allocates from, whereas the fragmentation I was talking about there didn't care much about the degree of fragmentation internal to heap, just how it effected the left over process address space. Probably there's some way to say that that is more clear and/or accurate.
User avatar
Alba Casas
 
Posts: 3478
Joined: Tue Dec 12, 2006 2:31 pm

Post » Wed Mar 09, 2011 11:27 am

andalaybay:
Worth a try. I've uploaded a 4.1.19 to tesnexus, along with a tbmm dll in a separate zip.
edit: iHeapAlgorithm=4 is now TBBMM (it used to be FastMM4 w/ debugging options). The messages in the log don't accurately reflect that in 4.1.19, that will be fixed in 4.1.20.
User avatar
Eric Hayes
 
Posts: 3392
Joined: Mon Oct 29, 2007 1:57 am

Post » Wed Mar 09, 2011 7:45 am

andalaybay:
Try lowering uGridDistantCount and uGridDistantTreeRange. To, like, 15 maybe. Maybe lower if necessary. Note that those are not uGridsToLoad - IIRC you should never change uGridsToLoad under any circumstances.
...snipped...


Ah, I wasn't sure which settings you meant. I haven't changed those either:

uGridDistantTreeRange=15uGridDistantCount=25


I guess I can try lowering uGridDistantCount to 15. I like my distant views though! So I want you to perform miracles - like every other mod user :D

Edit: Just saw your second post - I'll try the new version before changing my ini :)
User avatar
Katie Louise Ingram
 
Posts: 3437
Joined: Sat Nov 18, 2006 2:10 am

Post » Wed Mar 09, 2011 7:55 am

iHeapAlgorithm=4 is now TBBMM (it used to be FastMM4 w/ debugging options). The messages in the log don't accurately reflect that in 4.1.19, that will be fixed in 4.1.20.

You can still get distant views with lower uGridDistantCount, but it requires LOD mods. Which may defeat the purpose since they lower performance. But at least it might produce some information about your issue.
User avatar
Ian White
 
Posts: 3476
Joined: Thu Jul 19, 2007 8:08 pm

Post » Tue Mar 08, 2011 10:57 pm

Trying it out... Placed tbmmalloc.dll in ComponentDLLs, replaced main DLL, deleted INI file, let it generate a new one.

Here is my edited INI

Spoiler
Master = {	_comment = You can turn on or off each distinct feature from here.	bManageFPS = 1	bHookCriticalSections = 1	bHookHashtables = 1	bReplaceHeap = 1	bLogToConsole = 0	bFix64Hertz = 1	bFlushLog = 1	iSchedulingResolution = 1	bExtraProfiling = 0	bExperimentalStuff = 0	iMainHookPoint = 1}Experimental = {	iReduceLongSleep = 2	bRemoveShortSleep = 0	iThreadsFixedToCPUs = 4	bReplaceRawRandom = 1	bSuppressRandomSeeding = 0	bMonitorBSShaderAccumulator = 0	iPrintSceneGraphDepth = 0	bReplaceExtraRandom = 1	bAlternateHeapHooks = 0	iHeapMainBlockAddress = 0}FPS_Management = {	_comment = Basic FPS stuff, switches to slow-motion on low FPS; in the past this has occaisonally produced bugs like the NPCs-dropping-dead issue; the issues are believed to be fixed but if you suspect you are having related problems you can try disabling bAllowSlowMotion which is the main suspect for any problems relating to FPS management	bAllowSlowMotion = 1	MaximumFPS = 30	MinimumFPS = 10	iSmoothFrames = 0	iSmoothMode = 0	iSleepExtra = 2	iFPS_Frequency = 4000	iSchedulingParanoia = 1	iHardMaxFrametime = 200}CriticalSections = {	_comment = CS stuff helps both Oblivion and Fallout significantly	_comment = most of the benefit comes from the Renderer+0x180 suppression (see overrides below)	_comment = modes: 1=vanilla, 2=fair, 3=staggering, 5=suppressed, 6=prioritize-main-thread, 7=deprioritize-main-thread	bEnableProfiling = 0	bEnableMessages = 1	bUseOverrides = 1	iDefaultMode = 3	iDefaultSpin = 1000	iStaggerLevel = 5}Heap = {	_comment = Heap replacement can produce MAJOR improvements in performance on Oblivion at a significant cost in stability	_comment = It crashes instantly on Fallout3, and would only produce a small performance improvement there anyway	_comment = It is not supported at all on Fallout: New Vegas at this time	_comment = Algorithms: 1=FastMM4 (requires external dll), 2=Microsoft (slow on XP), 3=SimpleHeap1, 5=ThreadHeap2	iHeapAlgorithm = 4	bEnableProfiling = 0	iHeapSize = 450	bEnableMessages = 0	iGenericFreeDelay = 0}Hashtables = {	_comment = The dynamic resizing option is buggy and not recommended.  	bAllowDynamicResizing = 0	bUseOverrides = 1	bEnableProfiling = 0	bEnableMessages = 1	bEnableExtraMessages = 0	iHashtableResizeScale1 = 2	iHashtableResizeScale2 = 4	iHashtableResizeDelay = 20}OverrideList = {	CriticalSection = {		CallerAddress = 0x701748		comment = Renderer+0x180, recommendation=suppress (mode 5)		Mode = 5	}	CriticalSection = {		ObjectAddress = 0xB32B80		comment = MemoryHeap CS, recommendation=stagger (mode 3)		Mode = 3		Spin = 1500	}	CriticalSection = {		CallerAddress = 0x70172A		comment = Renderer+0x80, recommendation=???	}	CriticalSection = {		ObjectAddress = 0xB3FA00		comment = Unknown4, recommendation=???	}	CriticalSection = {		ObjectAddress = 0xB33800		comment = BaseExtraList, recommendation=3		Mode = 3		Spin = 1500	}	Hashtable = {		comment =caller 0x00418E16		SizeAddress = 0x00418DDB		OldSize = 37		NewSize = 149	}	Hashtable = {		comment =caller 0x0045a8a1		SizeAddress = 0x0045A866		OldSize = 5039		NewSize = 133123	}	Hashtable = {		comment =caller 0x004A25BC		SizeAddress = 0x004A2586		OldSize = 523		NewSize = 2711	}	Hashtable = {		comment =multipart 1/2 - caller 0x004e614f		SizeAddress = 0x004E610F		OldSize = 37		NewSize = 47	}	Hashtable = {		comment =multipart 2/2 - caller 0x004e614f		SizeAddress = 0x004E612C		OldSize = 37		NewSize = 47	}	Hashtable = {		comment =caller 0x004E9014		SizeAddress = 0x004E8FD7		OldSize = 37		NewSize = 739	}	Hashtable = {		comment =caller 0x004f0e20		SizeAddress = 0x004F1B44		OldSize = 37		NewSize = 127		WordBits = 8	}	Hashtable = {		comment =caller 0x004f1d60		SizeAddress = 0x004F220A		OldSize = 7001		NewSize = 7001	}	Hashtable = {		comment =also caller 0x004f1d60		SizeAddress = 0x004F222E		OldSize = 701		NewSize = 901	}	Hashtable = {		comment =also caller 0x004f1d60		SizeAddress = 0x004F2B70		OldSize = 37		NewSize = 127		WordBits = 8	}	Hashtable = {		comment =multipart 1/2 - caller 0x004F2ACB		SizeAddress = 0x004F2A8B		OldSize = 37		NewSize = 713	}	Hashtable = {		comment =multipart 2/2 - caller 0x004F2ACB		SizeAddress = 0x004F2AA8		OldSize = 37		NewSize = 713	}	Hashtable = {		comment =multipart 1/2 - caller 0x004f2b3e		SizeAddress = 0x004F2AEF		OldSize = 37		NewSize = 1301	}	Hashtable = {		comment =multipart 2/2 - caller 0x004f2b3e		SizeAddress = 0x004F2B12		OldSize = 37		NewSize = 1301	}	Hashtable = {		comment =caller 0x0067fbb0		SizeAddress = 0x006C5396		OldSize = 37		NewSize = 83	}	Hashtable = {		comment =also caller 0x0067fbb0		SizeAddress = 0x0067FD35		OldSize = 191		NewSize = 3019	}	Hashtable = {		comment =also caller 0x0067fbb0		SizeAddress = 0x0067FE5F		OldSize = 191		NewSize = 2021	}	Hashtable = {		comment =caller 0x006C56B0		SizeAddress = 0x006C5674		OldSize = 37		NewSize = 299	}	Hashtable = {		comment =caller 0x00714788		SizeAddress = 0x00714752		OldSize = 59		NewSize = 239	}	Hashtable = {		comment =many callers: 0x00769C3D, 0x00769CAD, 0x00769D03, 0x00769D53, 0x00769DA1		SizeAddress = 0x00769BEB		OldSize = 37		NewSize = 297	}	Hashtable = {		comment =multipart 1/2 - caller 0x009dbf36		SizeAddress = 0x009DBF03		OldSize = 131213		NewSize = 905671	}	Hashtable = {		comment =multipart 2/2 - caller 0x009dbf36		SizeAddress = 0x00B06140		OldSize = 131213		NewSize = 905671	}	Hashtable = {		comment =caller 0x009e2726		SizeAddress = 0x009E26F3		OldSize = 37		NewSize = 297	}	Hashtable = {		comment =caller 0x00a10de6		SizeAddress = 0x00A10DB3		OldSize = 37		NewSize = 297	}}


The logfile
Spoiler
initialize0() running in thread cdcinitialize1() running in thread cdcinitialize2() running in thread cdcCritical Sections mode 3 (staggered prioritization)MemoryHeap Optimization Algorithm 4: attempting to replace the Oblivion heap manager with FastMM4 debug / debug.dllusing hashtable size overridesHashtable size override: 00418DDB : 37 -> 149Hashtable size override: 0045A866 : 5039 -> 133123Hashtable size override: 004A2586 : 523 -> 2711Hashtable size override: 004E610F : 37 -> 47Hashtable size override: 004E612C : 37 -> 47Hashtable size override: 004E8FD7 : 37 -> 739Hashtable size override: 004F1B44 : 37 -> 127Hashtable size override: 004F220A : 7001 -> 7001Hashtable size override: 004F222E : 701 -> 901Hashtable size override: 004F2B70 : 37 -> 127Hashtable size override: 004F2A8B : 37 -> 713Hashtable size override: 004F2AA8 : 37 -> 713Hashtable size override: 004F2AEF : 37 -> 1301Hashtable size override: 004F2B12 : 37 -> 1301Hashtable size override: 006C5396 : 37 -> 83Hashtable size override: 0067FD35 : 191 -> 3019Hashtable size override: 0067FE5F : 191 -> 2021Hashtable size override: 006C5674 : 37 -> 299Hashtable size override: 00714752 : 59 -> 239Hashtable size override: 00769BEB : 37 -> 297Hashtable size override: 009DBF03 : 131213 -> 905671Hashtable size override: 00B06140 : 131213 -> 905671Hashtable size override: 009E26F3 : 37 -> 297Hashtable size override: 00A10DB3 : 37 -> 297hook point 1: hooking call to main game functiontimeBeginPeriod: 0 -> 1Improved_GetTickCount seems to be workingHeap Initialization (268435456, 0)CS 0x00B32B80 (caller 0x40100A, path 0, spin1000), by-object, set to mode 3CS 0x00B32B80 (caller 0x40100A, path 0, spin1000), by-object, set to spin 1500CS 0x00B33800 (caller 0x40100A, path 0, spin1000), by-object, set to mode 3CS 0x00B33800 (caller 0x40100A, path 0, spin1000), by-object, set to spin 1500CS 0xFF2D5300 (caller 0x701748, path 0, spin1000), by-caller, set to mode 5initialize3() running in thread 24f0, renderer at FF2D5180thread 3B9C assigned PT 0331B888, serial# 1thread 23B4 assigned PT 0331B918, serial# 2thread 24F0 assigned PT 032303D8, serial# 3FPS data, time:21s, avg: 18, extremes: 0-200, current:  13thread 0D14 assigned PT 03230468, serial# 4FPS data, time:25s, avg: 16, extremes: 9- 78, current:  15FPS data, time:29s, avg: 18, extremes:13- 30, current:  17FPS data, time:33s, avg: 16, extremes:11- 28, current:  16


It lasts maybe 10 seconds at most, and then CTDs. It crashed no matter whether I had Experimentals on or off.
User avatar
dell
 
Posts: 3452
Joined: Sat Mar 24, 2007 2:58 am

Post » Wed Mar 09, 2011 9:29 am

It's stable on mine, at least in limited testing. Performance numbers (units are ns per operation, not ns per malloc like in the numbers I listed for simple tests) as measured just now on my Oblivion install:
5 ThreadHeap2: 67 ns
4 TBBMM: 57 ns
3 SimpleHeap1: 109 ns
2 Windows Heap (on XP): 1394 ns !!!
1 FastMM4 (old version): 68 ns

TBBMM outperformed ThreadHeap2 by a tiny bit in-game. ThreadHeap2 outperformed FastMM4 by an amount too small to be statistically significant. FastMM4 outperformed SimpleHeap1 by a bit. And XP was visibly slower than the rest, even though I was testing with a reduced uGridDistantCount setting which makes the differences harder to see while playing. The others I could not tell the difference between in-game.

My assumption is that your problem is just one more in the long list of "some Oblivion installs hate some heap managers for no reason".
User avatar
Max Van Morrison
 
Posts: 3503
Joined: Sat Jul 07, 2007 4:48 pm

Post » Wed Mar 09, 2011 9:49 am

With the new TBMM heap, I can get to the menu, but when I try to load a save file, I get a CTD while loading. The last line in my log is the serial #3 thread being assigned.
User avatar
dean Cutler
 
Posts: 3411
Joined: Wed Jul 18, 2007 7:29 am

Post » Wed Mar 09, 2011 11:57 am

ver. 4.1.19
with tbbmalloc.dll enabled

no additional ddls loaded and only oblivion.esm activated

crash (CTD) after load save and crash (CTD) after new
User avatar
K J S
 
Posts: 3326
Joined: Thu Apr 05, 2007 11:50 am

Post » Wed Mar 09, 2011 2:51 am

Okay... maybe TBBMM is working for me an no one else?
I ran it through about 5 minutes of very high speed exterior travel on my computer, but not much else.
User avatar
Prohibited
 
Posts: 3293
Joined: Tue Jun 12, 2007 6:13 am

Post » Wed Mar 09, 2011 11:10 am

Okay... maybe TBBMM is working for me an no one else?
I ran it through about 5 minutes of very high speed exterior travel on my computer, but not much else.


I'm just getting the new version loaded now. Will report back shortly.

I'm running RAEVWD, so I can lower uGridDistantCount?
User avatar
April
 
Posts: 3479
Joined: Tue Jun 20, 2006 1:33 am

PreviousNext

Return to IV - Oblivion