Talk:Minimizing your Script

I just added something re: script optimization that we knew from Morrowind scripting - it looks like Haama determined that the same thing is true for Oblivion in November '07 (good on you mate). The thread linked at the bottom of the page contains performance data that proves the same is true for Oblivion. --Halo112358^talk 03:50, 30 May 2008 (EDT)

Potential early return problem

I'll start off by pointing out that I'm a relative scripting newbie, so take this with a pinch of salt!

Based on my observations (or perhaps trying to track down various "it doesn't quite work properly" bugs in my code), it would appear that the early return recommended in the gamemode block doesn't only cancel further execution of that block but the entire script: it seems that once return has been called, any subsequent blocks you might expect to run in addition to gamemode, for example "begin onpackagestart", won't.

Somebody with more experience may wish to confirm or deny this (though if the latter, an explanation for what I'm seeing would be helpful!) but it does seem at face value to be an important caveat to bear in mind. --cbh 13:41, 7 May 2009 (EDT)

Well, that's what the Return function is meant to do - Prevent the iteration of the script for the rest of the frame. You can absolve some part of this by placing the gameMode/menuMode block at the end of the script.

shadeMe TALK 16:57, 7 May 2009 (EDT)

Yes, Return stops a script from running entirely on the frame on which it is caused. It should only be used when you do not want to run the script at all anymore on that frame. It does improve performance, but only marginally, and this is rarely a major concern for scripts.

Dragoon Wraith TALK 19:50, 7 May 2009 (EDT)

Thanks for the clarification: I'd assumed that each "begin" block was analogous to a function, and each relevant block would be called separately by the underlying game engine, so a "return" in a "gamemode" block wouldn't affect a subsequent "onpackagestart" block. However, it seems that they're processed not as functions but as big "if" statements. A matter of semantics, but one that can easily cause confusion... (and bugs!) --cbh 20:14, 9 May 2009 (EDT)

Just to follow up the above, I now see that the Return page in question makes this abundantly clear--so much for making assumptions! --cbh 20:21, 9 May 2009 (EDT)

Uncertainty

I'm not sure this article is a very good idea. The advice seems heavy-handed for the effect - it is very rare for scripts to have any performance issues at all. "Avoid a GameMode block at all costs"? No. In fact, there are a number of reasons to use a GameMode block even when another block would work - OnEquip comes to mind immediately as an excellent situation where using a GameMode block with a conditional is much better than using the specific block (since OnEquip does not work for items that are equipped with EquipItem). Giving this kind of advice without much better advice on why you should or shouldn't do certain things strikes me as unwise. It's only going to confuse people, like Cbh up there.
Dragoon Wraith TALK 19:53, 7 May 2009 (EDT)

I've just been pondering this, and was wondering if anybody feels like attacking the article? I took the recommendations to "avoid using gamemode whenever possible" and about early returns giving "dramatic performance gains" to heart and have subsequently been tripped up by both of them more than once; arguably one instance could have been avoided by checking the documentation (though given the potential for making erroneous but not unreasonable assumptions about what "return" does, I think that such advice should be offered more cautiously: or at least with a better explanation of the consequences) but I do have to wonder if the performance gains are really dramatic enough to encourage the adoption a coding style that's contrary to good programming practice, being a definite risk factor for mistakes and consequent bugs... However, as someone who is still not a particularly experienced TES scripter, I barely feel it's my place to comment let alone amend the article, so I'll leave that to someone else! But I do have fairly serious concerns about the appropriateness of such recommendations, or at least the strength with which they're asserted. --cbh 11:06, 14 May 2009 (EDT)

I completely agree with you, but I'd really like some other opinions from experienced scripters. I've always been very much in favor of scripting (and modding) primarily for myself, so performance concerns beyond "does it run on my machine" have never been an issue for me. At the same time, I've read (and participated in) the tests, and I have a pretty good idea of what are performance issues and what are not - and scripts almost never are. As you say, the advice here confuses code and involves scripting that is confusing and obtuse - and I guarantee you, that in almost all cases, the performance gain is perfectly negligible. Even if said script was running on a thousand objects concurrently, for most scripts I doubt you'd see a difference in FPS at all.

Dragoon Wraith TALK 16:41, 14 May 2009 (EDT)

The page needs to be changed. The most likely situations that are going to effect FPS through high CPU usage are doing things with a high amount of complexity (i.e. algorithm with n^2 worst case) or doing something silly (iterating through hundreds of references per frame, infinite loops, etc). All of these cases when improved would offer a dramatic CPU decrease. The tiny effect of scripts on FPS can be seen by making small programs in a language such as C and timing them. One will quickly realize that the improvements suggested in the article improve script speed linearly and on an order of magnitude in nanoseconds. Even running the code for many iterations and summing the saved time would yield only milliseconds of gained time at best. The problem with scripting and FPS is algorithm complexity. If your fancy OBSE script is making n^2 comparisons a frame, you can gain much more by using something that works in linear or logarithmic time instead of saving the CPU 3 clock cycles by early returning or not using a conditional. Note that a modern CPU can decode multiple instructions per clock cycle at well over 3 billion cycles per second. I say redo the article. Sabar 07:34, 10 August 2009 (EDT)

Absolutely true, but as someone who has "only" taken four college-level computer science courses, you are pushing the limits of my understanding already - an article that gets into algorithm complexity is much too involved for this Wiki, methinks.

As I said above: Yes, and in fact I'd be in favor of deleting it entirely until someone has the time to rewrite it (or just doing without otherwise), but I am biased and only one person, so I want more opinions.

Sigh. Maybe it's time to ask on the Forums. I hate having to do that... Wiki matters should stay on the Wiki.

Dragoon Wraith TALK 11:55, 10 August 2009 (EDT)

Well, I for one, second the article's deletion/rewrite.

shadeMe ^TALK 17:15, 10 August 2009 (EDT)