Speeding scripts up

[THobson]

Maybe I wasn't clear.  

The @ command generates much less video lag than a goto loop with a 0.5 second delay in it.

[h-]

@THobson
Doesn't that really depend on what you have inside the loop...

If you have nearestObject call(s) or for example camCreate/createVehicle or drop, those will kill your FPS in matter of seconds when using @...

[Dinger]

How are you measuring "video lag"?  (I presume you mean an FPS hit)

[THobson]

Basically I wanted to test the view that an @ is always more damaging to lag than a loop.  I placed 5,000 empty BMPs on the map each with a script run from their Initialisation field.  In one run through the script had the following:

@ (getDammage thisunitname > 0.98)

and in another run through it had

#wait
~0.5
if (getDammage thisunitname <=0.98) then {goto"wait"}


Provided the player could not see the BMPs : With the first there was no detectable lag at all.  With the second the lag was ugly, really ugly.  I even changed the script so there was a random delay at the start so that all the 5,000 scripts were not naturally synchronised.  Still it was very ugly.

I agree that with more complex condition statements the loop might be better than the @  Each case should be tested specifically.  The purpose of the exercise was for me to determine which of these constructs I should use in my own mission to detect when a vehicle was badly damaged.  The answer was the exact opposite of what I was being told would be the case.

It was in trying to understand why this was the case that, I believe, led to the thinking that the placement of the labels might be having an impact.

EDIT:

Video lag - yes I mean fps.  The reason I specified video lag is that there does seem to be another, more subtle, underlying lag issue that manifests itself in the form of dumb AI, even though the fps remain okay.

EDIT2:

I believe this might be the thread that started this:
http://www.ofpec.com/yabbse/index.php?board=6;action=display;threadid=24542

[Dinger]

Lag is the time delay experienced in network games as a result of network travel time, available bandwidth and server load.


The test in question is interesting, but "scanning for labels" is not the only or the most compelling explanation.

With 5000 scripts, it would not be unexpected to see each script get called at an interval greater than .5 seconds, so in this case ~.5 might be equivalent to an @ command.
Also, starting with a random increment isn't going to be enough for the same reason: it'll exceed each of those waits and end up bumper-to-bumper anyway.
Moreover, since each line of code gets allocated an approximate temporal value, running a goto loop has twice the lines of code (~, ?:goto) as an @ statement, so right there you could get twice the slowdown -- maybe three times.
And the conditions are not quite equal. > and < are, cpu-wise, much less intensive operations than >= and <=.


So this test would demonstrate that if you're going to run a whole bunch of scripts checking a condition, and those scripts have an ~ interval shorter than the time needed to run through all those scripts, than an @ statement may be more efficient.

[THobson]

I am not sure that is what people usually mean by lag on this forum.

I tried it with < and > as well as with <= and >=.  There was no detectable difference.

I am not with you on the bumper to bumper logic.  The number of lines look an interesting explanation.

In any event I chose to use the @ command in this particular case.

[Dinger]

the term "lag" gets abused. It aids greatly if the terms are used properly.
Lag refers to a delay. FPS chunders and FPS slowdowns are not delays, but decreases in performance. That's why they're not lag.
"Lag" got applied to FPS problems incorrectly as a result of poorly-written MP code (like Doom, HL1, and so on), which required all units to be synchronized to proceed. An out of synch unit would freeze or create stutters. Soon by synechdoche people were blaming all stutters on "Lag".
It's not a problem for general diagnostics, but when you're trying to sort out complex phenomena, such as what produces the best performance for the network, the individual CPUs and so on, you need to be precise.

"Bumper to bumper" logic isn't logic, it's a conjectural explanation of the phenomena, just like "searching through for the label" is a conjectural explanation of the same phenomena. The only difference is that I've offered evidence (analysis of savegame files) that falsifies the latter conjecture.
I'm glad that < and =< have no discernable difference: that indeed suggests that the actual time spent by the CPU processes the instruction is insignificant compared to the time spent parsing it.
Anyway, good luck with your research.

[h-]

the term "lag" gets abused. It aids greatly if the terms are used properly.
Lag refers to a delay. FPS chunders and FPS slowdowns are not delays, but decreases in performance. That's why they're not lag.
"Lag" got applied to FPS problems incorrectly as a result of poorly-written MP code (like Doom, HL1, and so on), which required all units to be synchronized to proceed. An out of synch unit would freeze or create stutters. Soon by synechdoche people were blaming all stutters on "Lag".
It's not a problem for general diagnostics, but when you're trying to sort out complex phenomena, such as what produces the best performance for the network, the individual CPUs and so on, you need to be precise.

I have heard that to be called desync (as well)...

Everybody I know refers  to the decreasements inf performance/FPS dropdowns as lag though...
Maybe because the phenomena is a bit similar to the desync happening in MP games, like you described..

I think the same goes with for example sound engineers/professionals "you want to add echo into some sound? There is no echo, there's only delay or reverb"...

Btw, what would then be the correct term for the decreasement in performance/FPS dropdowns? Or is there a term for that?

[penguinman]

i know this thread is about speeding up scripts so i was wondering,

if you were trying to catch a bullet at a certain time, would running two scripts at the same time increase the chanses of catching it. because i know scripts arent fast enough to catch a bulllet at a certain point.

[Chris Death]

@Thobson there's just one thing that makes your test not
equal in comparisation:

@ (getDammage thisunitname > 0.98)

Here you check for damage being higher then 0.98



#wait
~0.5
if (getDammage thisunitname <=0.98) then {goto"loop"}

And here you check if damage is lower or equal than/to 0.98

Also like Dinger already pointed out that by such a mass of
scripts running, the @ command will lose it's efficiency of cycling.
Suma once said IIRC that the @ command will check for every
frame or so, what again supports Dinger's theory in this case.

You should enhance your test by checking out what will happen
if one of those 5.000 tanks reach the damage limit;

Which variant will then react faster?

Also you should maybe make equal checks for both variants:

#loop
?(dammage _thisunit > 0.98): exit
~0.5
goto "loop"

You might now say that you were saving one line with your
version, but you and i cannot for sure say that a complicated
one-liner is more eficient than 2 simple lines - only a new test
can proove right or wrong again.

And btw - yes - LAG is the result of desync and will show up
like: you shoot another guy but he doesn't die because on
his end of the internet he is already somewhere else, just
your pc didn't get the right info yet.

But ppl tend to use the word LAG for things like: performance loss
or framerate dropdown aswell - probably because LAG is such
a nice word, or just simple 3 characters, or just accepted by
almost the entire comunity to be used in this case.
But that's not the point of the discussion me thinks.

Btw, what would then be the correct term for the decreasement in performance/FPS dropdowns? Or is there a term for that?

I would tend to say: slow-motion or dia-show (slide-show)  ;D  

~S~ CD

[THobson]

You will see in a later post that I also used < > as well as <= and >= in the tests, with no obvious effects.

I don't understand how your four liner helps - I don't want it to exit.  There would need to be another goto and another lable, making it quite an ugly construct.  (Note there was a typo in my original that I have now corrected - I had goto"loop" when it should have been goto"wait")

Your comment that 5000 scripts will make the @ lose efficiency is interesting.  The @ performed very well in the test it was the loop that died.

I am sure there are many ways of defining lag.  The OED has many one of which is 'fall behind'.  When the video output falls behind the action that is lag just as much as lag occuring over a network, there is also lag that occurs when the work the engine has to do causes some of the ai IQ raising activities to fall behind the action resulting in dumb ai.  The problem is not that the word lag is being used incorrectly, it is that on its own it is not sufficiently descriptive of what is happening, so we should be talking about network lag, video lag and possibly even ai IQ lag.

[Chris Death]

I don't understand how your four liner helps - I don't want it to exit.

OK, but the fourliner is doing exactly the same as your @ example.

Your if opposite than @ then goto doitagain might be much more work for the processor to be understood than the condition you were using in your @ statement.

Your if statement might look tricky but it's hell of a lot more complicated than the @ condition you were using  - multiplied by 5000 this will make a big difference.

that's my point here

Your comment that 5000 scripts will make the @ lose efficiency is interesting.  The @ performed very well in the test it was the loop that died.

OK, that's now my bad English (not my native language), therefore i'll try to explain it again on another way:

The @ command will check the condition to be met for every available frame (so SUMA from BIS said).

This means if you have 60 frames per second the @ command
will check 60 times for the condition in a second.

Now if you run 5000 scripts at the same time, the frame rate will
drop down - tho i'm not sure if it's meant to be the same frame
rate we're talking about when making performance tests
with some frame rate testing tools.

With @ loose efficiency i meant that the check-interval for the
condition to be met will change according to the decreasing frames
available, while 0.5 seconds will always be 0.5 seconds.

- btw i found another word for LAG which i forgot at the end
of my last post: delay ;D

~S~ CD

[Nemesis6]

I work a lot with particle scripts in OFP, so how's the "speeding" on the attached script? Am I getting it right? I'm thinking of reworking the FlashFX scripts with the techniques shown here... that is, of course, if I've gotten it right.

[Mikero]

@Nemesis

Yep, you've got it right with the possible exception of the #loop scriot. If you consider the #loop to be where most of the time will be spent in this .sqs, as in the explosion stuff is realy just more intiatilase and wont be repeated, then the #loop, should be at the top.

@others

line numbers aren't used by the engine.

meat cleavering Lag to mean only internet lag is silly. Lag existed long before the internet was ever thought of. The generally accepted sense of it here is some performance hit on the video display making a timing constraint between mouse acti0ons and what-you-see, but I seriously doubt anyone has any difficulty understanding lag in the context it is mentioned.

[Mr.Peanut]

So what is the minimum ~delay to use for a loop before it makes sense to use @ instead?