I was thinking of adding compression to the aero data to improve loading times, but before I went ahead I decided to check how long it took, and clocked it at ~1.6s. From what I remember, it took 4s with the old aero data, which had to be rotated (e.g. vertical-body force to lift, etc) so tons of trigonometry. While working the aero, I deleted all of that and made the tables already in the axis that Orbiter wants == gain. So I think I'll leave it as is, as it's about 0.1s per file, and each is on average about 30kB in size, so I don't think compression would gain much in here.
As I had "the clock on my hand", I decided to time the Atlantis class constructor (~3.2s) and the scenario loading (~3.7s), places were most loading happens.
I was somewhat surprised by the numbers, so I decided to dig a bit more and the loading of meshes is by far the driver here: 98% of the time in the constructor! The Orbiter.msh alone takes almost 80% of it!!! :uhh:
Although I didn't dig much in the scenario loading, I'd guess most time also goes to mesh loading (RMS/ODS/VC panels), although I'm sure parsing the scenario file takes some of it.
All of that in MOGE. In D3D9, mesh loading times increase almost 10x, with 12.6s needed to load the Orbiter.msh file, probably a result of the more data structures that have to be created for the extra visuals, and the extra textures that also have to be loaded.
I'm wondering if the order of the mesh groups affects the loading and, or only, the rendering? (material and texture switching)
In any case, I'll write a script to re-order the mesh groups, so that doesn't have to be done by hand, but manual intervention will still be needed for transparency details. :shrug:
Another +/- performance related thing is all the unused DPS files and logic. I don't think that is costing many milliseconds, but in the end it's not being used, so I think I'll delete all that, first in the SimpleGPC_IO branch to test and make sure there are no issues, but it isn't my intention to rush this to make the SSU 5.0 train.