havent read all of this, so my excuses if this has already been mentioned.
Reducing lag when having max no of units on the map
1) Use COC's AI on demand system
This places all the stipulated units in stasis until required.
There re initialisation can be brought about by comparing the distance of their position to the nearest enemy unit or by a boolean
(Group waypoints are also seen as a possible position of these "In Stasis" units)
I've use it, its very good although sometimes you do see a slight stutter as these units are re introduced)
2) Place units in cargo in a vehicle and then when ready setpos the vehicle, unnasign them units from the vehicle and delete the vehicle. Very low cpu intense method
hope that helps
as was said before reduce triggers to a bare minimum, and if you need a lot of west knows about east or activated by west type triggers then simply use the one trigger and setpos it to each location every second or so
3) Place all your commonly used global variables in ram memory by stating them in a .sqf which you run once at the start of the mission.
Place any commonly used script or segments of (That dont have "wait until" or "goto" statements in them) into functions and then call these functions from scripts
an example
The following system is made up of a looping script that calls a number of functions every so many seconds
(forget the content, its basically monitoring conditions that a bunch of triggers used to do)My method in my scripting is to have where possible
ONLY 1 looping script. Which i call my monitor script
It looks for certain condition and then when true runs a linear script (Non looping) which runs it commands and then exits
In the example below i check a lot of endgame conditions,
Check the blue line out, this runs the checkA function
The beauty of this is, the function, which is basically a linear script is already in memory, it doesnt require the hard drive to be accessed or data written across to ram, its much more instant and therefore a lot less cpu intensive
the looping script?!(local server):exit
~ 3 + random 1
#INIT
_a = 0
#START
~1
if(tx_StopSqs)then{goto "END"}
_a = _a + 1
if((_a == 3)&&(({alive _x}count tx_destroy)==0))then {call loadfile "tx_sys\server\CheckB.sqf"}
if(_a == 4)then {call loadfile "tx_sys\server\CheckA.sqf"}
if ((_a == 5) && (count tx_damcon >0))then{{_x setdammage 0} foreach tx_damcon}
if(_a >=5)then{_a = 0}
goto "START"
#END
;; does some boring end of mission stuff then exits
exit
checkA.sqfif((((tx_EatStart - tx_Enow)/tx_EatStart)* 100)>=tx_Ecaslimit)then{tx_Ecashigh=true;tx_StopSqs=true;tx_Efail=true; {Publicvariable _x}foreach["tx_StopSqs","tx_Ecashigh","tx_Efail"]}
else
{if((((tx_WatStart - tx_Wnow)/tx_WatStart)* 100)>=tx_Wcaslimit)then{tx_Wcashigh=true;tx_StopSqs=true;tx_Wfail=true; {Publicvariable _x}foreach["tx_StopSqs","tx_Wcashigh","tx_Wfail"]}
else
{if((((tx_RatStart - tx_Rnow)/tx_RatStart)* 100)>=tx_Rcaslimit)then{tx_Rcashigh=true;tx_StopSqs=true;tx_Rfail=true; {Publicvariable _x}foreach["tx_StopSqs","tx_Rcashigh","tx_Rfail"]}
   else
{if(time >= tx_timelimit)then{tx_StopSqs=true;tx_timeout=true; {Publicvariable _x}foreach["tx_StopSqs","tx_timeout"]}
   };
};
};
The above stuff is used in a template for A&D missions, when the template is bug free all the long variable names will be changed to a much smaller string length
as am sure many have pointed out before in this thread
few more tips
try never to use @
better to use
#start
~0.5
?(condition):goto "SKIP"
goto "START"
#SKIP
the refresh rate for the @ command is that of a trigger
also think about reducing setviewdistance
or smoothing of the terraingrid
for some reason boats use a lot of cpu, probably because the system has to keep recalculating their height as the waves come in.
Infantry patrolling through woodland is also cpu hungry
long distances between waypoints is another
use of lots of drop commands is another, eg campfires, flares, anything that burns or gives of light basically