@abassign, thanks for checking the FDM theory.
In general, you will find that "events" is for Nasal timers.
However, you will want to use the http/telnet interfaces to watch the performance stats, because the GUI dialog using PUI/Nasal is dead-slow, and even adding to the overhead you are seeing
Once you have confirmed that flight/fdm still is fairly high, despite not showing up in standalone JSBSim mode as such, you have basically narrowed down the problem - for instance, it's usually FDM-coupled Nasal code, i.e. listeners triggered by FDM properties, that is causing this.
To check if that's the case, I would next comment out the <nasal> section in the Su15-set.xml file to prevent Nasal modules from being loaded. If the theory is correct, the overhead for events/flight should be much lower.
In summary, what you are seeing and interpreting is misleading/incorrect - you really need to understand how this works under the hood - i.e. the FDM showing >= 100 iterations is to be expected because it runs several times per frame, which also means that offloading this onto a separate core may not get you much/anything at all, especially should there be FDM<->Nasal code running 100+ times per frame (which seems to be the case so far).
Please make sure to read & understand this:
http://wiki.flightgear.org/Howto:Use_the_system_monitorIf you should be able to confirm that it's Nasal related, the next step would be to identify the corresponding callbacks.
For the whole background on the Nasal GC, see:
http://wiki.flightgear.org/How_the_Nasal_GC_worksAlso, regarding the term "processes" you used in this context: FG is basically using cooperative multi-tasking-imagine it like a team of people (15+), all of whom need to finish their work and hand it over to the next person, so that a single frame can be produced - with some people (subsystems) being allowed to redo/check their work several times in a row (fdm, autopilot), while others will only get a single opportunity to update their internal state.
Finally, it is this "team of people" that will produce a single frame - so whenever "someone" is too slow, it will end up causing stuttering. No matter the reason, scenery/terrain, Nasal etc - at some point, another subsystem will have to wait, which means fewer frames created per second.
I think this is also where vitos failed to interpret correctly what he was seeing - but you really can draw reliable conclusions once you render the model in standalone mode, and then run the FDM in standalone mode.
In both cases, you will obtain the "maximal theoretical performance" of each system (in isolation), so that you can check if/how complexity of the 3D model and/or FDM is playing a role here.
Next, you would do the same thing with Nasal code, i.e. by disabling it entirely and watching performance then.
Overall, it makes sense to team up with Hamza, because he's meanwhile pretty experienced with benchmarking FG meanwhile, so you could learn a lot, while also improving the quality of your bug reports, as well as your whole troubleshooting process
None of this is changing anything about the complexity of the model though
To see for yourself, you can use osgconv to reduce the complexity and see for yourself just how much faster frames can be rendered