most likely nothing can be done here - creating a new entity is complex (loading the model and texture data, allocating memory (RAM+VRAM), initializing the simulation, loading sounds, etc)

the workaround to preplace the vehicles or create them via sqf at mission (pre)init is the best you can do.

How does createVehicle work?

something like this:

• Model called
• Textures are loaded with setObjectTexture ?
• simulation
• sound
• setFuel
• setAmmo
• setPylon
• setSupply
• addCargoItems
• initEH
• etc.

To understand, if an object is in memory, are the timings drastically shortened the next time it is created due to the speed of the memory?

Is it not possible to perform a kind of cloning?

Wouldn't it be useful or good to work out a way of splitting up these tasks that are carried out in createVehicle? This would only have to take place with extremely performance-hungry objects (I would always call initEH separately for the purpose of modding).
The splitting could be done over several frames or, as Dedmen is currently very successful in splitting the process over several cores, this is also an option.

We can call the new way generating object creatVehicleSafe. I do the same thing in my mission, if I manipulate the object.

This would improve the first time loading and the repeated loading, since the timeings of some objects are very high anyway.

Speaking as third party observer with a little bit of developer experience and some knowledge of how games/software works, there is little point in changing the current system of createVehicle with regards to initialization.
If you need certain assets to be loaded consistently fast in run-time conditions, then you should prespawn those as "dummy objects" and immediately delete them once you initially enter run-time conditions.
It is justified (and sane) as the developer of the game to leave the existing system as it is, because your case is easily a much more niche use-case than the cases most people use Arma for.

I, curiously, happen to have such a use-case, and Arma 3 typically consumes about 3GB RAM started from desktop, but will easily balloon to 10+GB double-digit numbers with extended playtime.
And then those numbers also run dangerously close to the x86 memory limit of 4GB, meaning if your system is x86 or x64 can and very much likely also is relevant.

You're also calling createVehicle without specifying the optional parameter special, which defaults to "NONE", which, and I quote:

"NONE" - will look for suitable empty position near given position (subject to other placement params) before placing vehicle there.

And therefore you may want to try repeating your measurements with this command:

test_fps = diag_codePerformance [{

    test_veh = createVehicle ["B_Plane_Fighter_01_F",[0,0,0],[],0,"CAN_COLLIDE"]

},[],1]

In fact, you may want to check out the Code Optimisation guide to get some clues about how the internal systems of the game work.

I find it really difficult to create a discussion here. For me, a feedback tracker is about information or possibilities to improve something and to discuss this with officials or to give information for improvements.
Maybe it is better to discuss something like this in the arma discord, here I am interested in official statements.

Also, if you read my posts correctly, there is nothing here about changing createVehicle, but offering an alternative or pointing out a problem in the possibly old code of createVehicle. Because unfortunately there are still a lot of old code forms or systems that have survived from OFP/Arma 1.

I've been here since OFP and I can tell you that in Arma 98% of the time, as we use it now, objects are created after the start of the mission. Whether in Arma life at the vehicle store, in Wastland when activating AI missions (PVP/PVE), at king of the hill to buy his vehicles (PVP) or what is most important to me in Milsim CTI/Zeus (PVE). So this is definitely not a niche.

In my self-scripted mission (for about 8 years), I have identified this as almost the only problem that still leads to short lags, and I can't completely eliminate it because I can't disassemble createVehicle. And whether an object is there in 1 frame or is created over 8 is completely irrelevant in my case.

Regarding your method for createVehicle with canCollied, you're right, I may have written it down incorrectly. But it doesn't make much difference in VR.

To your second sentence, you don't need to repeat it, it's already in my post above how I solve it.

Regarding save usage, if you have a properly scripted mission this won't happen and this whole thing about restarting the server every 4 hours is complete nonsense if you script it properly.

For me it would be important to achieve an improvement, especially for airplanes and tanks that already perform jerkily when you create them.

How does createVehicle work?

its all done in engine (c++) - not chained sqf commands

Because unfortunately there are still a lot of old code forms or systems that have survived from OFP/Arma 1.

in general 20 years ago with far less memory, way slower cpu+ram, etc it was way more important to have the engine as efficient as possible.

so while possible, it is unlikely that such core elements are inefficient

Maybe it is better to discuss something like this in the arma discord, here I am interested in official statements.

if you are lucky Dedmen will notice this ticket, read it and respond. you can try to bring it up on arma discord too ofc.

Okay, thx for the infos. For now i think dedmen has to much to do with his current work. Maybe I'll bring it up nicely next year.