ah yes...
Not a 'time critical' example that, but a good example to show that you don't need to include the use of an _x in a foreach loop.
[granpa voice] Back in my day, we didn't have Call, and ForEach on a null value was the only way to do call a string.[/granpa voice]
Now, the discussion:
The goto method described is indeed how I learned that Commodore BASIC processes things.
Whether OFP does, is a different question.
Frankly, I've seen a lot of debate over scripting efficiency over the years, and few people actually basing their theory on anything other than conjecture and parallel reasoning. Folks, those aren't theories, those are hypotheses.
UNN's objection is a valid one, and I'll build on it:
You can save the game state at any time, and look at how the data is stored.
If you look at the scripts section, you'll find that scripts are stored, stripped of comments and blank spaces, in a line-by-line fashion, with each line assigned a number.
Labels are stored separately, as pointers to the line that follows them. This seems to be true even if you have a bunch of labels at the end that are never used.
Therefore, it seems safe to assume -- in the absence of other evidence -- that the method Mikero describes is
not the case. Now it may very well be that it
is faster, but not for the reason given -- any performance improvement will be a result of the label appearing towards the top of the stack of labels. In any case, I'd like to see some verifiable tests before taking this as dogma.
As for Shin's hypothesis, it's hard to say what exactly happens.
REmember the "preview" in the mission editor is not necessarily the same as running a mission from the mission pbo: the mission editor preview intentionally allows the editor to change scripts "on the fly" -- at least those not running in memory (n.b., if a script is running in memory in the mission editor, and you alt-tab out, change the .sqs, and try to start a new instance of that script, it'll run the old one).
So
it has not been determined whether on mission start, the whole mission pbo is loaded into memory, or only the parts that are needed. However, if mission pbos work anything like addon ones (and there is little reason to doubt it), one would suspect they and their contents are mapped to memory at mission start.
So my counter-hypotheses, backed up by what little OFP experience I have:
1. Outside of Mission Editor missions, missions are mapped to (real or virtual) memory2. When a script is called, it gets parsed into the "game-state":
2.1 Comments and white space are stripped.
2.2 Functions and Wait instructions (@ and ~) are assigned line numbers
2.3 Labels are mapped to line numbers, and put in a separate pile
2.4 Any improvement gained by rearranging file lists is negligeable when compared to the performance costs of parsing instructions at runtime.
Now go show me I'm wrong.