In the SQF engine setDamage is a wrapper to setDammage, meaning its a few operations longer than setDammage. I would suggest reversing them internally so the newer, properly spelled version of the function is the actual function, and setDammage is the wrapper.
- Legacy ID
- No Bug
This has been present since setDamage was introduced, but the fix would literally take 20 seconds of copy pasting. If someone has a few seconds at the end of the day or the start why not throw in a slight performance buff for SQF. :P
I'm thinking you are guessing this. There is no difference, test it yourself.
["player setDamage 0.1"] call BIS_fnc_codePerformance;
["player setDammage 0.1"] call BIS_fnc_codePerformance;
In fact setDamage in my tests applied to player appeared to be teeny weeny bit faster. On the spawned helicopter they were equal.
Because I looked at the actual opcodes, its a wrapper to setDammage. It calls the normal allocation functions for both, but setDamage just is a wrapper that calls setDammage and then performs the return.
If it is indeed actually faster with more operations then something odd is going on in the SQF engine, or I am not seeing some sort of optimization they are doing.
Unable to reproduce. They're equally fast.
Also it depends on the complexity of the scenery. If you look at the sky and time any of the commands, you'll get 300%+ faster timings than if you look across the landscape.
I performed the following tests at 30km altitude with absolutely nothing to render but the sky.
All results are the average of 1,000,000 executions.
setDamage: 5.98779 microseconds
setDammage: 5.96704 microseconds
setDamage: 5.606616 microseconds
setDammage: 6.08496 microseconds
setDamage: 6.00391 microseconds
setDammage: 6.08398 microseconds
I've made more tests than these, and it always changes between setDamage being the fastest and setDammage being the fastest.
In either case, it's safe to assume that this issue should be closed.
I have checked the code and it's true that setDamage is only a wrapper for setDammage but the wrapping overhead is optimized away by compiler. So MulleDK19's measurements make sense - there shouldn't be any difference.