Jump to content

question about code optimization


Recommended Posts

The Wiki text says:

"the script engine would process all code inside of an If block (even if the condition was false) until the script engine could find an exit point. An exit point can be either an accessible RETURN call, or the end of the script."

 

My reasoning:

 

The word 'process' cannot refer to execution . . . . (execution does not go into false condition code),

so it must refer to some pre (or post) process the engine runs

This process stops on the first return if finds (if any) . . . . (go figure)

This process is unnecessary . . . . (or it would not be recommended to circumvent it)

Reordering the code blocks and adding a Return at the beginning of the script aborts the process . . . . (as the Wiki example)

 

If these premises are true, then adding a dummy return would improve performance.

If any is false, then all I said in this thread should be scratched.

 

WAIT. . . a different interpretation just occurred to me:

Premisses:

The script engine is an interpreter

No pre or pos processing

 

Consider this example:

Begin GameMode
  if  Gamehour < 12
    <code block A>
  else
    <code block B>
  Endif
  <code block C>
End

If Gamehour < 12 the interpreter executes <code block A> and, THEN, has to go thru (and not execute) <code block B>, line by line, looking for the matching Endif. When the Endif is found, it executes <code block C>.

If Gamehour >= 12 the interpreter has to go thru (and not execute) <code block A>, line by line, looking for the matching Else and then executed <code block B> and <code block C>.

 

But suppose there is no <code block C>, as in the Wiki example.

 

In this case, it makes sense to add a Return after <code block A>

Begin GameMode
  if  Gamehour < 12
    <code block A>
    Return
  else
    <code block B>
  Endif
End

If Gamehour < 12 the interpreter executes <code block A> and hits the Return. In this case it does not have to go thru <code block B>.

If Gamehour >= 12 there is no gain. The interpreter still has to go thru (and not execute) <code block A>, line by line, looking for the matching Else and then execute <code block B>

 

Does not exactly match what the Wiki text says, but makes more sense than my first interpretation.

 

It would save some processing time (although I still think it is negligible).

 

 

(yes, my mind hurts)

 

 

 

 

Link to comment
Share on other sites

@Moktah

I did some more testing by moving my test script into a MenuMode block and added a small GameMode block above it. My framerate was normal (350-380) in GameMode and dropped to around 40 (can't remember exactly) in MenuMode. It looks like this quirk is limited to the block that was called and not the blocks that aren't currently running. And yes, StopQuest completely stops any script attached to the quest.

 

 

 

Thanks for testing that for me.

Thats exactly what I was trying to figure out when I started this thread.

 

I knew the script engine was (as I call it) 'reading' all the rest of the script whether it needed to or not.

I was using this 'quirk' to my advantage in my menu's script.

It gives me a nice 'timed' feel to it in order to animate my setpoints and scroll behavior.

Grant it, in hind sight, I may have been better off creating smaller blocks of code rather than

one long "lets do almost everything from here" code.

 

The worry came when I was scared it would try to "read" my script outside of menumode.

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...