If this statement alone is not enough for you, than let me explain.
What the author did here, is called in software development premature optimization. Premature optimization is a process, to go ahead and optimize all kind of things, without identifying first, if they truely make a difference in performance. How is this achieved? Through profiling. Profiling helps to identify specific areas, which are causing delays, for things, which will be executed that many times, that they actually will matter to be optimized and will make an actual difference.
The issues with this mod are multiple:
- Only one man did this optimization. How is it ensured, that the author did not introduce new unknown bugs in the optimizations, by overseeing something? Actually, the example in the description tab, already DOES introduce a different condition and as such a possible bug.
Spoiler:
Show
The original code is checking for the condition getstage MQ15 == 66 and getdistance player 1000 on the second if statement. The third if statement which checks for suicide=1, does not check for getdistance player 1000, nor does it have a dependency on the previous if-statement. However, the optimized version, wrap the suicide=1 check inside the getdistance player 1000 check, which now introcuded a new condition and modified behaviour - maybe that last if will never trigger anymore. If that is the case, the supposed behaviour will not work anymore!
- There has been no continuous updates, for fixing bugs, nor maintenance for newer Oblivion versions, or for the introduction of new DLCs. It is not even stated, based on which Oblivion version these scripts were taken to be optimized.
- There's no way, to modify and select what is being loaded, based on the DLCs you have or don't have.
- On today's computers, a few thousand more condition checks and some other things don't matter at all. Variable checks are so quick, that often, It has to be in the hundred of thousands or million times executed, before you'll start seeing improvements in the ms area. (exceptions apply on heavy function calls sometimes, of course).
- There has been no quality assurance process for all the changes done in the scripts.
- There has been no benchmarking done with this. Optimizations without proper benchmarking, or any benchmarking at all, can be safely assumed to be purely subjective.
- This has not been tested with several non-vanilla mod setups - it can't be assumed easily, or actually at all, that these changes will be safe or working with them, even if the author claims, that the scripts are doing the same (see first issue, they may not actually do so, no matter if the author believes so - and even if condition changes may work on vanilla, there's a possibility they could be failing with mods). Either way, mod creators, are not testing with this active!
- There is another issue with several complex mods. Mods which load as .esm or OBSE plugins, may already change scripts and as such behaviours from the vanilla very early. The file included is an esp, which loads actually rather too late in the process, even if added first in your load order. It can't be loaded before OBSE or .esm plugins, and as such may overwrite scripts which were already modified and break compatibility with such mods.
- There is no process to report bugs, analyze bugs and fix them, and provide fixes over the last 15+ years. It cannot ever assumed in software development, that a software, neither a refactoring of existing code (that's what the process is called done by the author here), is ever bug-free. Every software developer is doing at times mistakes, sometimes even on the most simple thing done a hundred times before. It's human nature.
- CPUs have changed since then a lot. Optimizations of that kind, may actually make some optimizations of the past either obsolete or worse. Actually, sometimes, code which seems on first sight that it should perform better, may perform actually worse for non-obvious reasons deep under the hood, as anyone who has done deep optimizations in software development, knows. Another reason, why premature optimization and trying to optimize just everything, may have varying results and is bad.
And if this professional advice still doesn't convince you, consider these:
- This has not gained the popularity it would require, to assume, that such a deep modification on original scripting, is working as intended.
- This has the potential to break your game unrecoverably, if some scripts are part of save games, than you may never recover from issues, even after uninstalling. I haven't checked if this is case, as I'm not going into looking on each and everything which was modified, but it's very well a possibility.
I used to work software projects and this sort of approach often helped improve performance. Since Oblivion always ran decently on my computer before I installed this, I couldn't tell if it made a big difference during game play. I'd need a program to measure the difference. But if you are having troubles with Oblivion on your system, this might be an answer.
No it's not. Put it first in your loadorder and let all other mods that touches the oblivion.esm scripts load after. The only one would probably be the unofficial patch. But then if it actually improves performance or not is another question. Read the comments
This messes with the scripts for Shivering Isles. Also if you uninstall this, Your game won't even start. It is no fun having to re-install all of your mods either.
name: 'HrmnsOblivionScriptOptimizationv1.0.esp' priority: -2 msg: - type: warn content: 'Not recommended for use as there is no measurable performance improvement, and it breaks the Shivering Isles by changing some FormIDs, causing a script to be written into cell data.' condition: 'checksum("HrmnsOblivionScriptOptimizationv1.0.esp",82FC20B' - type: warn content: 'Not recommended for use as there is no measurable performance improvement.' condition: 'checksum("HrmnsOblivionScriptOptimizationv1.0.esp",FEED7422)'
In the description, your analysis of the default script vs your script is incorrect. This leads me to believe your optimizations are not truly up to scratch.
For instance, the default script is actually doing this every frame no matter what: * if timer <= 0 * if timer <= 0 (again) * if suicide == 1
This is considering those three checks all prove to be false. This shows you do not have a full understanding of what is known as short circuit logic, the && symbolizes a logical AND operator, which means "if one AND two" is true. Obviously you knew that, but what it seems you don't know is, if the first is untrue the second is not checked. Short circuit logic dictates that the rest of the if statement is left unchecked and the statement returns false.
So, in the case of the descriptions example script:
if timer <= 0 && getstage MQ15 == 58 && OrtheRef.getdead == 0 set timer to 5 sayTo player MQ15EldamilWarning endif
if timer <= 0 && getstage MQ15 == 66 && getdistance player < 1000 if suicide == 0 set timer to sayTo player MQ15EldamilWarning set suicide to 1 endif endif
if timer <= 0 if getstage MQ15 == 58 && OrtheRef.getdead == 0 set timer to 5 sayTo player MQ15EldamilWarning endif
elseif getstage MQ15 == 66 && getdistance player < 1000 set timer to sayTo player MQ15EldamilWarning setstage MQ15 67 endif endif
The suicide variable has been completely removed as it was unnecessary with this script, the getdistance function takes more processing power than the getstage function so it should be done last in the elseif (as was already done in the default, I am explaining why it was) since short circuit logic will completely bypass this check unless it is absolutely necessary, and all extra if checks were moved inside of the mandatory timer <= 0 check.
This new script will at least always do this every frame: * if timer <= 0
That is all. I hope this has been insightful, and please hit me back. I have been programming in C++ since early 2012.
Basically, when Oblivion read "if" it will (in this order): 1) Read the whole if block searching for an exit point: EndIf, Return, RemoveMe (for inventory objects) etc... 2) Evaluate the whole if condition (DOESN'T SUPPORT SHORT CIRCUIT AND/OR)
So, it check the whole condition block even if the condition is false, then execute the whole if condition. For the point 1, you could test it using a loooong if block with a false condition, But even checking 5000 lines can barely impact a fraction of the FPS (unless you're using a pre-'90 computer!)
As for the second, you can easily test it yourself with a simple script:
ref testVar ;this is null
Begin GameMode If ( testVar ) && ( testVar.isActor ) ;do stuff EndIf End
The first condition check if testVar is not null. Since testVar is null it should stop (in a normal language). But... you will get a Null Pointer Exception! The game will try "testVar.isActor" even if the previous condition is false!
Wow, I am appauled at this new learning. I wonder what the reason behind forcing this extra evaluation is... I mean, it is pointless and actually forces extra CPU cycles.
Huh, I did not know this about Oblivion scripting. My first thought was this mod could be updated in light of this news (e.g. inserting RETURNS throughout scripts to short-circuit them). However, when I actually cracked this mod open in TES4Edit and took a look at what scripts were actually modified, almost all of them are one-time usage scripts. Of the ones that aren't, they all have limited usage. Moreover, very few of these would ever actually be running together. It would be one thing to optimize heavily-used scripts, but I really don't see the point in optimizing a script that will only ever run once.
So this mod fails on multiple levels: (1) it doesn't actually optimize anything (2) it potentially makes the scripts more unstable, and (3) the scripts it tried to optimize wouldn't have an effect on the game anyway.
Give Feedback
105 comments
If this statement alone is not enough for you, than let me explain.
What the author did here, is called in software development premature optimization. Premature optimization is a process, to go ahead and
optimize all kind of things, without identifying first, if they truely make a difference in performance. How is this achieved? Through
profiling. Profiling helps to identify specific areas, which are causing delays, for things, which will be executed that many times, that they
actually will matter to be optimized and will make an actual difference.
The issues with this mod are multiple:
- Only one man did this optimization. How is it ensured, that the author did not introduce new unknown bugs in the optimizations, by overseeing
something? Actually, the example in the description tab, already DOES introduce a different condition and as such a possible bug.
- There has been no continuous updates, for fixing bugs, nor maintenance for newer Oblivion versions, or for the introduction of new DLCs. It is not even stated, based on which Oblivion version these scripts were taken to be optimized.
- There's no way, to modify and select what is being loaded, based on the DLCs you have or don't have.
- On today's computers, a few thousand more condition checks and some other things don't matter at all. Variable checks are so quick, that often, It has to be in the hundred of thousands or million times executed, before you'll start seeing improvements in the ms area. (exceptions apply on heavy function calls sometimes, of course).
- There has been no quality assurance process for all the changes done in the scripts.
- There has been no benchmarking done with this. Optimizations without proper benchmarking, or any benchmarking at all, can be safely assumed to be purely subjective.
- This has not been tested with several non-vanilla mod setups - it can't be assumed easily, or actually at all, that these changes will be safe
or working with them, even if the author claims, that the scripts are doing the same (see first issue, they may not actually do so, no matter
if the author believes so - and even if condition changes may work on vanilla, there's a possibility they could be failing with mods). Either way, mod creators, are not testing with this active!
- There is another issue with several complex mods. Mods which load as .esm or OBSE plugins, may already change scripts and as such behaviours from the vanilla very early. The file included is an esp, which loads actually rather too late in the process, even if added first in your load order. It can't be loaded before OBSE or .esm plugins, and as such may overwrite scripts which were already modified and break compatibility with such mods.
- There is no process to report bugs, analyze bugs and fix them, and provide fixes over the last 15+ years. It cannot ever assumed in software development, that a software, neither a refactoring of existing code (that's what the process is called done by the author here), is ever bug-free. Every software developer is doing at times mistakes, sometimes even on the most simple thing done a hundred times before. It's human nature.
- CPUs have changed since then a lot. Optimizations of that kind, may actually make some optimizations of the past either obsolete or worse.
Actually, sometimes, code which seems on first sight that it should perform better, may perform actually worse for non-obvious reasons deep
under the hood, as anyone who has done deep optimizations in software development, knows. Another reason, why premature optimization and
trying to optimize just everything, may have varying results and is bad.
And if this professional advice still doesn't convince you, consider these:
- This has not gained the popularity it would require, to assume, that such a deep modification on original scripting, is working as intended.
- This has the potential to break your game unrecoverably, if some scripts are part of save games, than you may never recover from issues, even after uninstalling. I haven't checked if this is case, as I'm not going into looking on each and everything which was modified, but it's very well a possibility.
But then if it actually improves performance or not is another question. Read the comments
http://www.nexusmods.com/oblivion/mods/31757/?tab=2&navtag=http%3A%2F%2Fwww.nexusmods.com%2Foblivion%2Fajax%2Fmodfiles%2F%3Fid%3D31757&pUp=1
name: 'HrmnsOblivionScriptOptimizationv1.0.esp'
'priority: -2
msg:
- type: warn
content: 'Not recommended for use as there is no measurable performance improvement, and it breaks the Shivering Isles by changing some FormIDs, causing a script to be written into cell data.'
condition: 'checksum("HrmnsOblivionScriptOptimizationv1.0.esp",82FC20B
- type: warn
content: 'Not recommended for use as there is no measurable performance improvement.'
condition: 'checksum("HrmnsOblivionScriptOptimizationv1.0.esp",FEED7422)'
You're right, but Oblivion doesn't work this way!
Read this: http://cs.elderscrolls.com/index.php?title=If section: "Oblivion evaluates entire If statement"
and this: http://cs.elderscrolls.com/index.php?title=Minimizing_your_Script section: "An important note on If blocks vs early Returns"
Basically, when Oblivion read "if" it will (in this order):
1) Read the whole if block searching for an exit point: EndIf, Return, RemoveMe (for inventory objects) etc...
2) Evaluate the whole if condition (DOESN'T SUPPORT SHORT CIRCUIT AND/OR)
So, it check the whole condition block even if the condition is false, then execute the whole if condition.
For the point 1, you could test it using a loooong if block with a false condition, But even checking 5000 lines can barely impact a fraction of the FPS (unless you're using a pre-'90 computer!)
As for the second, you can easily test it yourself with a simple script:
The first condition check if testVar is not null. Since testVar is null it should stop (in a normal language).
But... you will get a Null Pointer Exception! The game will try "testVar.isActor" even if the previous condition is false!
Thank you for explaining this!
So this mod fails on multiple levels:
(1) it doesn't actually optimize anything
(2) it potentially makes the scripts more unstable, and
(3) the scripts it tried to optimize wouldn't have an effect on the game anyway.