pedeathtrian

austin_medic, what your tool does is called static code analysis. Being great thing by itself, it however does not substitute "live" debugging and profiling. Crapload of AI is controlled by FSM AFAIK, which is in turn script itself. Having a powerful CPU, lots of RAM and super-duper fast SSD are not exuses for not optimising code. Performance pitfalls can hide everywhere. Even in libraries everyone used to trust. PS. There's always space to optimize some code. Especially in the field where nobody ever used profiler.

For all reports I'm using the file from your post with 2.1 release message. To clarify the exception steps to reproduce: clicking in the free space should be done before some file is selected, i.e. when selection is clear. Otherwise simply nothing happens. There must be very few files to not fill the list space entirely.

Wrong line numbers in report. When in fact it's 18th line. is given for 34th line, i.e. 2n-1.File has \n line separators (LF, 0x0A).

Exceptions in SQFanalysis tool 1. Select folder with files. 2. Click in empty space in list with files Exception text Loaded assemblies

About page says tool has version 1.8.0.0

Getting arrays of available headgears and uniforms. allwdHg = []; allwdUf = []; { allwdUf pushBack getText(_x >> "uniformClass"); // if collecting headgears for all classes if (isArray(_x >> "allowedHeadgear")) then { allwdHg append getArray(_x >> "allowedHeadgear"); }; if (isArray(_x >> "allowedHeadgearB")) then { allwdHg append getArray(_x >> "allowedHeadgearB"); }; } // 1 is for WEST guerillas, i.e. B_G_* classes, which FIAs are count ("getNumber(_x >> 'side') == 1" configClasses (configFile >> "I_G_Soldier_base_F")); allwdHg = (allwdHg arrayIntersect allwdHg); allwdUf = (allwdUf arrayIntersect allwdUf); Non-guerilla units seem not to have allowedHeadgear* arrays. Hope that helps.

I'm interested in profiling SQF code and/or creating profiling tool for SQF. Does prof build provide information I can use for it? (More details in this post.)

A post of clarifications (I hope). When I write some code (mostly C/C++) I usually first write it, debug it and then profile when needed. I'm quite new to SQF, but the habit is strong, so I find lack of profiling tools kinda disappointing. So I wanted to write profiling tool for SQF, but first I investigate the possibility of such tool creation (here comes this topic). The tool that could produce output similar to gprof for example, with Flat profile, Call graphs and Annotated source (since I always know what __FILE__ script runs, on what __LINE__, and I can loadFile it for annotation). Line by line would require too much changes to source code, so I wasn't planning to impement it. Script writer would be able to put some marks in his code (just like diag_tickTime, but with collecting this info). Every time execution hit the mark, some info is stored somewhere for later analysis. After some (possibly a lot) of executions, analysis is done and information in one of the mentioned formats is logged. Then script writer reads it and eliminates bottle necks in his code; sees what functions call what and possible detect code that is not executed at all. Some coverage testing can be done also. If implemented using macros, this method would only affect performance in debug/profiling mode and only be used by script writer on development stage. It will always have some overhead on preprocessing stage though. Everyone in community could benefit from existence of such tool: developers create more effective code; players get missions that run faster; fps rises; everyone happy. SQF codebase and its complexity rises day by day. At some point in the future there will be definitely a necessity of having such tool. Ideally there would be built-in profiling capabilities for SQF (e.g. in prof build), which would not require much changes to source code, but I don't expect it to appear. The problem now is I cannot rely on diag_tickTime command for implementing such tool for the reasons provided in this topic earlier. Probably, on long runs this will not influence too much and stats will strive closer to real numbers, I dunno. Thx to MarkCode82 for mentioning diag_activeSQFScripts. I think it's possible to implement sampling profiling on top of it (though it's not very accurate and wasn't my goal initially). Thx to killzone_kid, I found those debug/prof branch builds with support for diag_*Frame commands. Will try it when prof build for hotfix is ready. For now, I'm still not sure if it porovides abilities to profile SQF code in the way I can get output in mentioned formats. If you have any information that can help me implement a profiler for SQF (or stop at once creating weird stuff), please share. Thank you.

Thanks for reply, deadfast. That's what I thought it would do. And that too, unforutnately. Actually I don't care about context switches, only about times. And seems like I found sort-of answer for my 3rd question. In the place I should've been looked first. On sleep's page in comments section Sbsmac writes:

I mean, if I had the "CPU clock" in addition to "wall clock" (diag_tickTime), that would be enough for me. I mean the ability to know how much time this script runs. The clock that stops when scheduler runs other scripts, and runs only when your script runs. Any OS has such clock for their processes (you can see it in task manager for example). Should require very small change to interpreter and insignificant overhead on execution. Then you can measure your code for the time it was really running, not some wall clock time.

Thanks for the link, Nikander. Indeed, good tutorial, but unfortunately, does not give me required info. Seems like I'm looking for something too strange and hardcore that it does not even exist (outside of BIS).

Profile, sorry for typo.

Seems like nobody ever wanted to profile their sqf code. Sad.

Check this article: addAction. on.sqf will look like: params ["_object", "", "_id", ["_args", [], [[]], [1,2]]]; _args params [["_rgb", [1,1,1], [[]], [3]], ["_br", 0.12, [0]]]; // defaults are white light with brightness 0.12 private ["_h", "_nom"] _h = getPosATL _object; _object removeAction _id; _nom = "#lightpoint" createVehicle position _object; _nom setposATL _h; _nom lightAttachObject [_object, [-0,0,0]]; _nom setLightColor _rgb; _nom setLightAmbient _rgb; _nom setLightBrightness _br; _object addAction ["<t color='#2EFE64'>Eteindre.</t>",{0 = _this execVM "off.sqf"}, [_nom, _rgb, _br]]; off.sqf: params ["_object", "", "_id", ["_args", [], [[]], [1,2,3]]]; _args params [["_lightSource", objNull, [objNull]], ["_rgb", [1,1,1], [[]], [3]], ["_br", 0.12, [0]]]; _object removeAction _id; deleteVehicle _lightSource; _object addAction ["<t color='#2EFE64'>Allumer.</t>",{0 = _this execVM "on.sqf"}, [_rgb, _br]]; When you first add "On" action to object (ususally right after acreate), specify light parameters manually: _rendre = _object addAction ["<t color='#2EFE64'>Allumer.</t>",{0 = _this execVM "on.sqf"}, [[1,0.1,0.1], 0.2]]; // for red light Later they will be kept in actions arguments. I also suggest you not use removeAllActions too much as it interferes with other actions being added to objects.

Those are all (bad) decorations to the idea of my post: you can get value from spawned code other than through global variable. _arr = []; _sh = _arr spawn { _this pushBack (2+2); }; // ... some time later // access _var = _arr select 0; // could become nil

1. assignAsCargo does not take array as right argument. 2. moveInCargo's right argument's second element in array must be Number, i.e. cargoIndex, not Array (in your case turretPath) 3. Even if you use _c_t3 instead of _c_t4 you might not sit all soldiers from squad on the same place (using same cargo index for all). Collect all free cargo indexes and move one soldier per one cargo index.

Arrays are passed by reference, btw. Not sure, but this might work: { // some scope private ["_arr", "_sh", "_ret"]; _arr = []; _sh = _arr spawn { // ... some code private _return = 2+2; _this pushBack _return; }; // .... waitUntil {scriptDone _sh}; _ret = _arr select 0; _ret }

This post contains misinformation. See next post for details. Hello, here I am again, now with some numbers. I wrote some testing code to compare performance of different implementations of shuffle function. So this is the report. 1. Testing environment CPU: Intel® Core i7-3770K CPU @ 3.40GHz RAM: 16 GiB DDR3 1600MHz OS: Windows 7 x64 Ultimate ArmA3: current stable version, main branch, 1.56.134787 Loaded mods: CBA_A3 current version from Steam workshop, 2.3.1.160220 Start parameters: -showScriptErrors -maxMem=2047 -cpuCount=8 -noPause 2. Testing code I created empty mission in VR; put trigger there and a rifleman in its area. After few seconds testing procedure starts working. mission.sqm: Testing code, "test_shuffle.sqf". Mostly functions to populate input arrays. Tested functions defined in lines pdth_fnc_shuf = compile preprocessFileLineNumbers "pdth_fnc_shuffle.sqf"; cba_fnc_shuf = CBA_fnc_shuffle; bis_fnc_shuf = compile preprocessFileLineNumbers "bis_fnc_shuffle.sqf"; bis_fnc_shuf_v = BIS_fnc_shuffleArray; Testing output is produced in the same order. pdth_fnc_shuf is the function I wrote for this task, slightly changed since the first post, thx to Greenfist for useful tip on for loop; defined in "pdth_fnc_shuffle.sqf": cba_fnc_shuf is unchanged function from CBA. bis_fnc_shuf is function based on BIS's BIS_fnc_shuffleArray with slight changes done by me to conform function specifications: produce new array, leave input array intact, fair shuffling (see first post). bis_fnc_shuf_v is unchanged version of BIS_fnc_shuffleArray. Works incorrectly therefore should be considered off competition. Only here for reference. Produces incorrect output (no fair shuffling), shuffles input array in-place (therefore shows good times). 3. Test run All functions are given exactly the same input, generated randomly by functions in "test_shuffle.sqf". Vanilla BIS_fnc_shuffleArray shuffles in-place, therefore called last. Time measuring done using diag_tickTime scripting command. Since function call can be fully performed (especially for small arrays) in very short period of time, therefore not being able to be measured accurately, all functions called in loops of equal amount of repetitions so produce enough delay to be measured. Times measured in seconds. Array counts used in test: [3, 10, 30, 100, 301, 1000, 3010, 10000, 30103, 100000]. At lest DEF_SHUFFLE_RUNS array elements are shuffled by each function for each array count. Average time calculated for single shuffle run is logged in report. Types used for populating array: ["ARRAY", "BOOL", "CODE", "OBJECT", "SCALAR", "SIDE", "STRING", "NIL"]. For each of given type, array populated fully with only this type. After all types tested, test run for array populated with mix of mentioned types. For "ARRAY" type, tested array is populated with arrays, in turn containing mixed types as their child types (should not affect the root). "ARRAY"s contain other "ARRAY"s too. Maximum tree depth is limited by DEF_MAX_DEPTH macro. 4. Report output: 5. Details on report output For each combination of array count, used element types, and tested function report contains a log line describing said parameters, count of elements in the output (some functions fail to shuffle arrays with nils correctly), how many times loop was run for given array count and how much time it took for average run of shuffle function. On big arrays some functions fail to do the task, probably because of insufficient memory for operation of their algorithm, I dunno. Those calls report 0 time, which of course os not correct. Also, I had to partially rerun tests because ArmA3 ran out of memory (on CBA's shuffle of 30k array of "CODE"). You can see it in timestamps. Still all functions were in fairly equal conditions. 6. Conclusions CBA shuffle sucks (sorry guys, but I've got numbers). Shuffles array of 30k "ARRAY" elements in 43 seconds. U WOT M8??? I had to limit test to 30k elements because of it. BIS shuffle does not work properly, but at least does it fast. When final array size is known, resize+sets work on par with pushBack on small arrays and better on big arrays. Much better. The bigger the array the better. Or, more precisely, it's pushBack who starts to work bad. The bigger the array, the worse. That doesn't mean biki lies about set and pushBack performance. It only considers single element insertion to the array's end position, not population of entire array. You can shuffle array in average O(N) time if use proper method. 7. Any questions?

Check fullCrew function. Looks like exactly what you need.

Thanks for the tip on loops. Looks reasonable: for with three Code blocks which could be any code should generally be slower then hardcoded iterated form. On others I kinda disagree. I need resize to make sure there's only one reallocation for all elements of array. Since I fill array consequently I can't rely on resize done by sets for the same reason: there can be multiple reallocations. For the same reason I cannot use pushBacks. They simply cannot work faster than one resize + multiple sets. Now writing script to measure performance of scripts for different types of elements in arrays, for different sizes, etc. UPD. I'm going to set up empty mission in VR and disable simulation for player. What else can I do to minimize side effects?

If you can test it against CBA and post the results here it will be great. I can't reach windows machine atm. Nope, I only have some basic info from biki and this forum.

Simply check for existance/non-existance of units before checking if they're in list: (!isNil "unit01") && (!isNull unit01) && (unit01 in thisList)

Checked their code. Still (probably) inefficient. Although they don't have two BIS_fnc_arrayShuffle's issues I mentioned in theme start post, they have some flaws: Creating a full copy of input array which is (probably) not actually necessary, causing huge memory overhead for complex element types and big elements counts. Using deleteAt on this copy which can lead to up to N*(N-1)/2 single element shifts (in worst case). Building up an output array from empty to full using pushBack, possibly causing multiple reallocations, whereas final elements count is known from the beginning. Again, I don't know how BIS array's guts work. Whether they have reallocations (shrinking block) after multiple deleteAt's (if so, one more disadvantage for CBA's way; if not, they have memory overhead, so no win there anyway). Or how operations-consuming deleteAt and pushBack are. Whether shifting element depends on element type complexity or not... Unless they use something special under the hood, abovementioned list negatively affects CBA's shuffle as well. OK, let's guess. Element type can be anything, so most likely some smart pointer to some variant class, and actual data stored somewhere else in heap. And array is some kind of vector. That way first flaw from my list diminishes since all elements from the copy go to output array without any reallocations or movements of actual data. Array reallocations will apply to smart pointer class type, so quite cheap (but still present). If only some BIS employees could give us some precious insider information on how to work extremely effectively with their arrays... :)

nearestObjects does not return mines. nearObjects does, as does allMines. BTW, what effect are you trying to achieve with _x setDamage 1? Seems like it has no effect on mines. Do you want mine to explode? Or just be removed?

Nope, sir! We almost a year behind now.