In relation with Streamline 3.1: Within Streamline there is the Streamsmooth option. I understand that this will work together with SR if the min and max FPS in Streamsmooth are set not greater than what is set in the SR .ini (Implicitly I understand they can be equal, is that correct?).

My main question is whether Streamsmooth will do other beneficial things if I let it run together with SR (and set as per above)? At least I want to avoid the situation where they are both trampling on each other's feet so to say and one might end up losing performance by employing both at the same time. So that's why I have disabled the Streamsmooth currently (but still using the other Streamline options ). Thanks for any insight.

As far as I know OSR is just limiting the fps but will not change the video settings. Many users are using SL and OSR together (me included) and it works fine.

Using Streamline FPS targets equal to your OSR FPS targets is a bad idea for two reasons:
1. OSR tends to enforce its targets ruthlessly. Depending upon exactly how it measures FPS, Streamline may never ever see any FPS numbers that lie outside of OSRs range, even for single frame FPSes. And since (I presume) Streamline looks at multiframe averages, its percieved FPS may have a tendency to not even touch OSRs limits so long as there is an occasional frame that isn't clamped.
2. OSR tends to round its targets internally. I've been trying to change this, but for the time being all OSR FPS targets are integer numbers of milliseconds per frame, and the exact rounding may vary slightly between different OSR versions. A target FPS of 30 should mean 33.3333... milliseconds per frame, which OSR may round to 33 or 34, meaning an FPS target of 30.3 or 29.4. Steamline, operating in floating point math with average FPSes taken over multiple frames, may end up being clamped inside of its range even if the numbers are supposedly inside OSRs range.

Allow a margin between OSR targets and Streamline targets, with OSRs being the more extreme. I'd suggest keeping a 5% margin between OSR targets and Streamline targets. (edit: that is, if your OSR targets are 20 to 60, then your streamline min should be at least 21 and your streamline max should be at most 57)

Though, actually, I'm not that fond of streamline and don't particularly suggest it at all. It makes my characters feet hover off the floor slightly, its default configuration reduces performance, and even with its ini set up I don't find any noticeable improvement compared to no-streamline. Or maybe they've improved those issues since the last time I tried it.

edit2: Asside from the issues with FPS targets, streamline and OSR should work perfectly together. They deal with unrelated things, asside from the detail that both pay attention to framerates. Though this may change in future OSR versions.

Great reply, thank you SkyRanger! I see... and I have now changed my OSR and Streamline/Streamsmooth settings somewhat:

OSR Max Frames: 40
OSR Min Frames:20
SLSS Max Frames: 35
SLSS Min Frames: 21

In OSR I'm using HeapMode "5" since "1" proved unstable. This leads me to the question whether you have ever found out when or on what systems HM=1 is running stable and when it is not? I know there are a million different PC configurations / hardwares possible. But maybe you have a suspicion? Really more my curiosity than actual necessity as HM=5 seems to be working great on my machine.

As to Streamline, I think I like the Streamsave function quite a bit, and the memory purging also seems like a sensible idea to me. But I have installed it only today, so I have no firm opinion on all that yet. I'll be watching out if I have any issues, along the lines you have said.

The reason(s) why FastMM4 (iHeapMode/iHeapAlgorithm 1) can fail is not really known. There are widespread reports that it is fixed for some people by a certain modification to how bashed patches are made, but that does not fix the issues for me (I don't even use a bashed patch). Given that FastMM4 is presumably well tested, the obvious candidate reasons would be either a bug in Oblivion (several possible kinds), a bug in my hooking of Oblivions heap, or a mismatch between the conventions used by Oblivions heap and FastMM4.
Oblivion bugs: The most likely candidates involve going past the end/beginning of a memory block, race conditions masked by the heaps locking, and built-in assumptions about allocation patterns. My suspicion is that multiple of those are going on in Oblivion. Find and fixing these kinds of issues is likely to be a nightmare. I am particularly suspicious of masked race conditions with regard to a few of the common reported minor errors associated with heap replacement.
Bug in my heap hooks: Most of major stuff clearly works or there would be much bigger problems, but there may still be issues with some of the more obscure stuff. The most likely candidates would be either my ignoring of the internal statistics Oblivion keeps about heap memory usage, or my ignoring of the flag that Oblivion passes to its allocation function that seems to determine what the appropriate response to out of memory conditions is.
Convention mismatch: There's not a lot of room for error here, as the basic conventions are fairly straightforward. There are a few ambiguities though: what to do with zero size allocations, what to do with reallocation calls with NULL for an old address, and what to do with reallocation calls with zero for a new size. From what I heard about the bashed patch issue it sounded like it was about some kind of mismatch in conventions. I did a little experimentation... all heaps OSR supports (including the native Oblivion heap) treat zero byte allocations as 1 byte alloctions, which matches the C standard. Reallocation to zero bytes has an inconsistent return value between heap algorithms though... it returns NULL for heap mode 2 and possibly for Oblivions fallback heap path, but does not return NULL for Oblivions normal heap or for FastMM4, and some versions of simpleheap1 and threadheap2. Failing to return NULL there is I believe (though am not at all certain) a violation of the C spec, though of course FastMM4 is not obliged to follow the C spec since it was written for Delphi. This may be a source of CTDs, and can be easily changed, though I'm not yet sure what the desirable behavior is at this point. The possibly inconsistent behavior of Oblivions native heap with regard to realloc(X,0) could conceivably be a source of vanilla Oblivion bugs as well.
Interestingly enough, what C documentation I can readily find gives ambiguous or contradictory descriptions of the correct behavior to realloc(NULL,0). When the native Oblivion heap is called with those parameters, it CTDs.

The StreamSave feature of Streamline is indeed very very useful. There are competitors that claim to offer that feature without the other stuff but I have never used those competitors so I can't really comment on them. I know nothing about streamline memory purging.

No idea either, but I don't have idea even what that means. The CTD was gone after reverting to older OSR. If you need load orders or anything, do tell.

Those Streamline/OSR FPS margings sound usefull, I'll have a look at what it does.

Here's what I've done so far:
HM 1: Fast, farely stable, apart from a remote wilderness crash(could be anything).
HM 3: White LOD waters and trees until water surface is touched. Still, slightly less fast than HM 1.

Baphometal:
One thing that may be relevant to runaway memory usage is, Oblivion normally has some kind of mechanism for dealing with low memory conditions where it tries to free up some physical memory somehow, presumably involving uncaching some resources or something. My heap replacement code partially clobbers the MemoryHeap::GetStats function, which is used by their find more memory function, so it may not work or not work as well when heap replacement is enabled.

Interesting discussion, although I cannot contribute much since I am not a software programmer. Just a small clarification thing. The various heapmode one can set in the OSR .ini file, for a WinXP 32-bit machine, listed from slowest to fastest would go like this:

0 -> 3 -> 5 -> 1

Is this correct?

The debug mode and the one which says "quite good for Vista", they can safely ignored for WinXP, can they not?

There's a new OSR4 alpha up, same location:
ftp://71.115.222.171/sr_Oblivion_Stutter_Remover.dll

This attempts to force all replacement heaps to use a single set of conventions. There's a slight performance hit from that but it's probably negligible. And I'm not sure I matched Oblivions native heaps conventions. But this might improve heap replacement stability, particularly with regard to bashed patches generated with unpatched / old versions of wrye bash.
Also tweaked MemoryHeap::GetStats behavior slightly, adjusted how MemoryCleanup was hooked (appeared to be redundant), changed rounding on min & max FPS (again), and probably a few other details I've forgotten.

Tommy__H:
Yes. Broadly. That's the anticipated order, though some people have observed (minor?) deviations. For me (on 32 bit XP as well), the differences between 1, 3, and 5 are not visible in casual testing.

:drool:

Downloading and testing.

Thanks for the update SkyRanger!

SkyRanger, :goodjob:

EDIT: Actually, I want to report quickly how my Oblivion experience went over the weekend, with OSR and full Streamline (that's including Streamsmooth) both installed. I played with the settings I stated a few posts back in this thread.

Overall, it went very well indeed.

Occasionally my FPS would exceed the max from the SL setting (35) and reach the OSR cap (40). No idea why that would happen, but OK, no problem with that. Most of the times FPS stayed between 30 and 35. Slowest I got was mid-to-high twenties, so I cannot say anything about effects at the minimum caps.

Sometimes there would be ONE stutter, and it would be from very briefly to really noticeable. And when it happens it is usually when I'm galopping outside on my horse. It may be that my computer is not fully optimized, but even if it was, this much (little) stutter I can easily live with. More importantly when inside (cities, dungeons, homes), it never stutters. Also when fighting with multiple NPC's (I got only to 3 plus myself this weekend), it is always very smooth, whether fighting outside or inside.

Best of all, the system seems to run very stable. Even in sessions of say 4 hours it never crashed and behaved always normally responsive. No memory leaking as far as I can tell. I don't know how much of all the positives can be attributed to OSR and how much to SL, but they seem to cooperate very well indeed and I keep them both installed for now.

Nice!

With the newest alpha i got a crash when talking to Jaufre after closing the gate in Bruma

Here's the http://www.4shared.com/file/178003090/39c3e78a/sr_Oblivion_Stutter_Remover.html

You might start by disabling hashtable resizing. That is Hashtables\bAllowDynamicResizing and/or Master\bHookHashtables. Though if a hashtable resizing had directly crashed it then probably the last log file line would be something about a resizing. Still, a hashtable resizing could have gotten something in to an invalid state that crashed a little later.

Beyond that... the log file tells me stuff about what kind of performance issues you see (mostly heap related, but also some other stuff), but doesn't show any reason for you to crash. An OCPS log would tell me more about the actual crash, though I'm not very good at using those.
Is this crash new with the latest alpha? If so then it's presumably related to something that changed, but since you're not using heap replacement there's not much that changed.

Hmm... Doing that reduced my crashes related to the dll to zero Thx, i've been using this since the first public alpha and it never gave me so much problems

Just a quick question

Where is the ini file where you edit the iHeap on this? where would it usually be located?

OSR produces an INI in the Data/OBSE/Plugins folder the first time you run Oblivion with OSR on.

The new alpha is working fine for me. Also, I've been meaning to mention that I use the dynamic hashtable resizing and have played for hours with no problems at all. I realize it might cause problems for others, but it's working great here!

Is the fast exit feature working correctly?

Heap Replacement:
So... did heap replacement change behavior for people with the latest OSR4 alpha? This one added some compatibility tweaks to the replaced heaps, I don't know if it would help or hurt, but it should do one or the other. At the very least it should make OSR no longer care whether or not you have the wrye bash patch. I think.

Fast Exit:
bFastExit should work fine. It's redundant on Oblivion though since it's basically the same thing as Fast Exit 2 - it's there for Fallout usage. It's also not guaranteed to stick around on Oblivion as I haven't gotten around to asking Scanti for permission for that - the hook used in the Oblivion variant is Scanti's, and I'm thinking it's a bad idea to incorporate basically the whole of another modders release in there. So fair chance that will become Fallout-only soon.

Also some versions of OSR will tend to do a semi-fast-quit if heap replacement is enabled, I think I was confused when I wrote that part of the code and it will be removed if it isn't already.

Dynamic Hashtable Resizing:
Really not recommended. It does (I think) improve overall performance in heavily modded games, I'm not sure how much. But it has multiple conflicts with bits of OBSE, and can screw a number of things up. I haven't figured out a good work-around yet.

Heap Replacement is working great and Dynamic Hashtable Resizing does not crash for me. I noticed the hashtable resizing gives me about 5+ fps.

I can't detect any difference. It certainly didn't hurt anything!

Maybe it's my imagination, but I seem to get graphic corruption (flashing textures, odd streaks in the sky, etc.) with CriticalSections iDefaultMode = 6 much more often than I do with iDefaultMode = 2.

Normally it only happens after an hour or more of playing, if at all. With iDefaultMode = 6, it happens more frequently - sometimes shortly after loading.