stuttering and settings for OSR and Streamline?

I'll paste some suggestions I've collected regarding OSR settings, hope it helps!

 

Arthmoor and others: size 1024 heap 6

 

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, 2=Microsoft (slow on XP), 3=SimpleHeap1, 4=TBBMalloc, 5=ThreadHeap2, 6=ThreadHeap3, 8=tcmalloc
_comment = Algorithms numbers 1, 4, and 8 require external DLL files in the Data/OBSE/Plugins/ComponentDLLs folder
iHeapAlgorithm = 6
bEnableProfiling = 0
iHeapSize = 1024
bEnableMessages = 0
iGenericFreeDelay = 0
bZeroAllocations = 0

 

 

bRemoveShortSleep should probably not be used in the absence of a many-core CPU - at least 4, preferably 6+.
Enabling bRemoveShortSleep is vaguely analogous to setting the spin on CSes to large values.

iThreadsFixedToCPUs definitely should not be used in the absence of a multi-core CPU - at least 2, preferably 4+.

iReduceLongSleep... 1 cuts in half the duration of any multi-millisecond Sleep calls, 2 cuts them to 25%, 3 to 12.5%, etc

Settings that might be worth considering include...

Hardware Threads (logical CPUs, due to either multicore or hyperthreading) vs settings:
1 HT - bRemoveShortSleep = 0, iThreadsFixedToCPUs = 0, iReduceLongSleep = 0 to 1 (probably 0)
2 HT - bRemoveShortSleep = 0, iThreadsFixedToCPUs = 0 to 1 (probably 0), iReduceLongSleep = 0 to 2
3 HT - bRemoveShortSleep = 0, iThreadsFixedToCPUs = 0 to 2, iReduceLongSleep = 0 to 2
4 HT - bRemoveShortSleep = 0 to 1 (probably 0), iThreadsFixedToCPUs = 0 to 2, iReduceLongSleep = 0 to 3
6 HT - bRemoveShortSleep = 0 to 1, iThreadsFixedToCPUs = 0 to 4, iReduceLongSleep = 0 to 3
8 HT - bRemoveShortSleep = 0 to 1, iThreadsFixedToCPUs = 0 to 6, iReduceLongSleep = 0 to 3
12 HT - bRemoveShortSleep = 0 to 1, iThreadsFixedToCPUs = 0 to 8, iReduceLongSleep = 0 to 4

 

 

OSR 4.1.26 crashes with bReplaceHeap = 1 when using OBSE Plugin MenuQue v10 BETA during these scenarios:

1) Entering your character's name on the character creation screen
2) Entering a name for an enchantment

This can be fixed by using OBSE Plugin MenuQue v9a.

Using an UFCOM, OOO+MMM+Fran, Cobl 173 and UL base mod install, the fastest and most stable setup for my Q6600 CPU with 4 GB RAM is:

bManageFPS = 0
bReplaceHeap = 1
bFlushLog = 0
bExperimentalStuff = 1
bAllowSlowMotion = 0
iFPS_Frequency = 0
iDefaultMode = 3
iDefaultSpin = 3000
iHeapAlgorithm = 1
iHeapSize = 640

iHeapSize is not used by 1=FastMM4 and 2=Microsoft as they are able to dynamically resize themselves.
A iHeapSize of 640 is a great performer when using ThreadHeap3, but not the most stable heap method on a heavily modded install.

Both 1=FastMM4 and 2=Microsoft heap have always been the most reliable for me, though I tend to lean more towards FastMM4 for a longer play-through before a possible (and extremely rare) CTD, which has only ever occured during Exterior to Interior transitions. I'm also using the Streampurge feature of Streamline in conjunction with OSR. If you're playing with a heavily modded install, you should absolutely clean any dirty plugins as reported by BOSS.

Follow my recommendations only on a fresh sr_Oblivion_Stutter_Remover.ini in case you have made changes that conflict with the above.

 

 

For what it's worth, here's a cut-and-paste of my OSR ini experimental section:

Experimental = {
iReduceLongSleep = 1
bRemoveShortSleep = 0
iThreadsFixedToCPUs = 2
bSuppressRandomSeeding = 0
bMonitorBSShaderAccumulator = 0
iPrintSceneGraphDepth = 0
bReplaceRandomWrappers = 1
bBenchmarkHeap = 0
bAlternate64HertzFix = 0
bAlternateHeapHooks = 0
iHeapMainBlockAddress = 0
}

Seems to me some folk said increasing "iThreadsFixedToCPUs = " depending on the cores of your particular CPU netted benefits. Notice that mine is ever so slightly raised above default. But then I have an Intel i7 CPU with eight cores (four of 'em threaded), and configured conservatively. I alas no longer recall the core-to-setting formula. I believe it is buried somewhere in the OSR thread, if not in utilities documentation.

ADDENDUM: Don't forget that you need to enable Experimental Mode via the color-coded setting below:

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
bExtraProfiling = 0
bFlushLog = 1
iSchedulingResolution = 1
bReplaceRandom = 1
bExperimentalStuff = 1
iMainHookPoint = 1

-Decrepit-

 

 

Disable bAllowDynamicResizing

 

bRemoveShortSleep is not recommended on Oblivion under any circumstances.

 

768 for iheapsize is smoother than default, (450) and settings of 512 or 1024. I hardly "feel" the grids loading when running through wilderness. I understand that every machine built is like a human, never the same. Just giving input

 

iHeapSize shouldn't be helping past 450 unless either you're playing very long game sessions of a VERY heavily modded game or your Oblivion is leaking memory for some reason. Memory leaks, even fast memory leaks, have been observed in some peoples copies of Oblivion, but are believed to be rare. They're suspected of being triggered by mods or combinations of mods,

 

http://forums.bethsoft.com/topic/1140777-relz-oblivion-stutter-remover/page__st__90

 

http://shshp.sourceforge.net/

 

demni: Nothing very important on Oblivion. Some very minor tweaks to some heap algorithms and some logging messages, I think. Most of the important changes since 4.1.23 have effected only Fallout 3 and/or Fallout New Vegas versions of the Stutter Remover.

All your threaded heaps cause BSOD for me in a FCOM-modded game (PAGE_FAULT_IN_NONPAGED_AREA). I always got a BSOD with ThreadHeap3 when loading from a save that was outside, and all of them occasionally when switching exterior cells. They seem to work fine in the vanilla game with the unofficial patches, though. TBBMalloc and FastMM4 cause CTDs with either c0000005 or c00000fd errors. The Windows heap seems to work great in all situations on Windows Vista x64, though. I recently played FCOM for close to three hours with no problem.

I just noticed the exact same thing. I'm using Win7 x64 with 8GB ram. When I changed my heapsize from 450 to 1024 I start to receive the same blue screens with the settings 5=ThreadHeap2 & 6=ThreadHeap3. After that I googled OSR, heap bsod and found this post.
I did what you mentioned in your post and changed heap to 2=Microsoft. The BSOD are gone.