I thank you for mentioning this. It is partly true though and I’d just throw my 2 cents here:
It is recurrent an assumption in the community, complex aircraft are taking more resources because of the complexity of the systems simulation. I agree it could be the case if such systems simulation is badly coded or if they are using data structure and memory access in such a way it is taxing the CPU more than necessary and more than could be achieved.
What is really paramount to performance with 3rd party aircraft add-ons is first and foremost the graphics path. This is were 80% of your frame budget is spent if you carefully develop the systems simulation with high optimization techniques in mind.
The other performance problem with most 3rd party add-ons is the intricacies of the SDK from within. What I mean by this is what is the simulator doing internally with all the SDK structures 3rd party gauges are using, and how could 3rd party code be implemented so that it can maximize the throughput, minimize latency and effectively don’t do the same thing twice.
The later is very dependent on the SDK bugs as well and I’ll give you a practical example if you’re a little bit knowledgeable with the FSX SDK. This is bug dating back to FS9 at least and is still present in P3D5 (although partly depending on some conditions). Here is:
-
The SDK is notifying gauges when it is their time slice to update. Usually gauges do their calculations upon such notification (PANEL_SERVICE_PRE_UPDATE)
-
The SDK is notifying gauges when it is their time slice to display. Usually gauges draw themselves in a buffer which the simulator will later display on screen (PANEL_SERVICE_PRE_DRAW)
-
Now make a basic gauge, jump in the aircraft in the 2D panel (remember this is from FSX), switch to virtual cockpit, then jump back to 2D panel. Your gauge will now receive double of some of these notifications…
Which begs some questions:
- How many know about this and why it is doing it? (there is a valid reason if you put your shoes in the SDK side).
- How many gauges are developed in such a way they won’t do the same thing twice, therefore, they won’t take unnecessary processing and unnecessary FPS?
- is Asobo aware of this and aware of how some 3rd party developers are falling in this SDK trap, so that they don’t let this happen again or document it clearly?
I can assure you the Reality XP GNS and the Reality XP GTN are not having any significant impact to the FPS not because they are running an external program but because these products are implementing highly efficient inter-process communication system between the simulator and the trainers and because they are also re-coding the trainers live in memory so that they use the minimum resources necessary (compare the trainer memory working set running standalone and running with Reality XP for example).
But a significant reason of the Reality XP implementation performance is also because the part of the product which is running in the simulator space, the gauge, is designed with best practices and best intimate knowledge of the simulator internals and its SDK, thanks to nearly 20 years of expertise! Which in addition to performance gives you capabilities beyond the limitations of the SDK such as 32 bits high-definition graphics (even in FS9) which is not otherwise possible as-is. The Reality XP gauges are not even using any graphics hack but plain old FS SDK basic feature set for this, only they are exploiting what is already there but hidden in plain sight.
Having said this, most 3rd party vendors I know of are doing a great job and are very knowledgeable, but you have to also understand most 3rd party vendors can’t go beyond the boundaries set forth by the SDK. Most FSX area products having poor performances were most often suffering from having to use the XML gauge system for both the logic and the drawing parts. This is a neat approach for the simulator in the sense it is lowering the entry level for producing gauges for example, compared to C++, but it is also not the most effective way and every gauge using it is suffering from the tradeoff between convenience and performance.
Fast forward to FS2020 and the Javascript gauge ecosystem and the thousands of messages about how this is taking so much FPS and the dozens of discussions with a fix trying to make it a better experience. In this case it is true the JS gauge ecosystem is much better than the XML gauge ecosystem of the past and Asobo has expressed a strong desire to make this, in addition to the WASM ecosystem, performant enough.
This is no better with X-Plane. There is for example SASL which is a very good framework and which is offering the same lower level entry to plugin development on X-Plane as the XML ecosystem did for FSX. However whenever you’re using an aircraft which plugin is using SASL you can really feel a performance hit compared to another aircraft using C++ plugin (these are rare nowadays). The hit is even more pronounced in VR where it can make a perfectly capable computer running way above standard in 2D performing poorly in VR just because of the SASL layer and the way 3rd party plugins are using it. It is even easier to spot with XP11.50 which is now offering a new Plugin Admin tool with per-plugin performance in micro seconds and relative FPS hit.
But I digress and back to your comment, the most dramatic impact on FPS is a sound and low level SDK with direct access and control to the simulator internals, along with a very fast graphics path. P3D4 and 5 have these low level paths via the PDK, XP11 has always had it too natively, and we’re yet to know if we’ll get the same with FS2020 in the end. Maybe we won’t need any in the end?
cheers mate
this is going to be bad brother
So we need a better more advanced SDK & Gauges. Osobo please, roll up your sleeves and make MSFS2020 break the FPS sound barrier into the future. 
