If you read again carefully, you will notice that I did hint at Nasal and Canvas, too.
Your observations may seem obvious to you, but they're far from it. In FlightGear, you will typically want ~60 fps (hz).
Nasal standalone can easily provide ~1khz (1000 hz) - Nasal also supports threading in FlightGear, and those threads will typically run at >= 500 hz.
The real bottleneck is not due to Nasal being interpreted - Nasal has certain I/O requirements which are poorly formalized, i.e. any extension functions called by Nasal must be executed inside th main loop, because there is no thread-safety on the FlightGear side of things (Nasal itself is indeed designed to be thread-safe). So, it's primarily those extension functions (property tree accesses) and the GC (garbage collector)
This has been extensively discussed over the years, and you are unlikely to come up with a full picture of the situation unless you happen to be an experienced C++ developer familiar with the way Nasal is integrated in FlightGear (SGSubsystem really just being a shell), while most code is actually invoked via timers (events) and listeners (properties).
Even experienced aircraft developers continue to fail drawing the proper conclusions when it comes to Nasal and Canvas. And in fact, when it comes to the Canvas, you could even set up a Canvas and manipulate that using property rules, i.e. without using any Nasal.
For the Canvas specifically, it would pay off to come up with additional native primitives (so called elements) - and potentially primitives that have a data provider linked directly - e.g. a dedicated mapping element with support for navdb queries, where the type of query would be specified, the range, center and a few styling related attributes for the symbols to be drawn - that would get rid of tons of Nasal code in the main loop, which also means less GC/property I/O "pressure". We kinda started developing MapStructure that way, but that's obviously still using Nasal under the hood.
Also, things like the MFD framework would ideally become a native Canvas element - so that people actually structure their MFDs/avionics using a well-encapsulated design, basically sub-classing from a generic MFD element with pages and page elements - this would solve a ton of issues, especially when it comes to optimizing things internally, it will be much easier to do so in a holistic fashion if people use a common interface.
Either way, even if you were to find an approach to run Nasal scripts outside the main loop, that would almost certainly not be applicable to existing scripts/addons. There are too many implicit assumptions at work here, i.e. all the dependencies are not properly formalized - so that things would get really fragile quickly.
One option we do have is coming up with new "modes" to run certain Nasal modules outside the main loop, while using a well-defined interface to talk to FlightGear. However, that kind of coding would look very different compared to what aircraft developers are used to now. It would be more akin to message-based programming (think MPI or even Emesary use by the FG1000).
But that only makes sense on a strictly opt-in basis, i.e. for new features - the addon system would be an ideal candidate for this, i.e. a dedicated environment for addons that may run outside the main loop, while still being written in Nasal. And, in theory, that would also work for new canvas avionics - i.e. coming up with a new runtime environment, where the corresponding Nasal namespace has no access to any main loop resources other than sending/receiving messages and working with its own private property tree/canvas tree:
http://wiki.flightgear.org/Howto:New_Ca ... tion_ModelEither way, for the time being, the main issue is the lack of proper diagnostics - most people (those without a core development background) cannot be expected to properly interpret Nasal related performance issues, and differentiate between the different causes (GC, property I/O, redundant callback invocation (timers/listeners), poor algorithms etc).
At this point, what would really go a long way, is adding additional diagnostics in the form of "live" properties, to look behind the scenes of the Nasal environment - i.e. in the form of samples taken to track GC internals (active/removed references/objects), property I/O (read/write accesses), listener invocations, timer calls, naPool reallocations etc
That's the kind of information that would ideally be provided by FlightGear in the form of live properties "per frame", so that people can use that to log such details to the console or a file, or even hook up the whole thing to the built-in OSG StatsHandler - and that's when people will realize that these findings will vary greatly, depending on startup/runtime settings (aircraft, scenery, environment etc) - so what's really missing is the equivalent of a "process monitor" for Nasal specifically, so that end-users and aircraft developers can make better bug reports, and provide actionable information to people able to fix up things internally.
Don't get me wrong, there clearly is plenty of optimization potential left when it comes to complex Canvas avionics (think FG1000), but that has little to do with Nasal being interpreted, and compiling Nasal to native code also doesn't magically solve the real problem. It is however unlikely that we will find a way to magically run existing Nasal modules outside the main loop without running into race conditions and synchronization bottlenecks - under the hood, the free-form nature of properties+Nasal makes FlightGear a rather chaotic petri dish actually, because people have so much freedom to implement their ideas, which also means that core developers cannot easily formalize data/flow dependencies between different modules, because the main loop is such an "anarchist" place the very instant the property tree and scripting are involved - in turn, that also means that people can get really fancy and implement sophisticated features without requiring support or endorsement from core developers (think bombable addon, local weather, earthview, space shuttle etc - all these features were developed on top of the very freedom and flexibility provided by this anarchist environment we tend to call a "flight simulator", whereas reality suggests it's as much a "flight sim" as vim or emacs are "just editors" )
The property tree, XML and Nasal are definitely contributing to many issues in FlightGear (and so is the Canvas), however
it's too late to put the genie back in the bottle: middleware/base package development (aircraft + fgaddon) has long surpassed core development in terms of manpower, resources and activity ... and it's these very building blocks that make it happen.
So all we can do is look at the facts, and the history to learn a lesson or two from that - and since backward compatibility is essential, you cannot just go and break stuff, you can only come up with new/better features and try to convince content developers to adopt those (i.e. due to better performance) - which inevitably means such improvements must be strictly opt-in.
Trying to deal with existing Nasal code and trying to offload that onto separate threads isn't gonna happen without re-architecting things - it's the equivalent of trying to turn a 20-year old car into an electric car, while riding on the highway
Like your posting is showing, people tend to misunderstand Nasal and FlightGear performance in general, and they tend to be drawing the wrong conclusions (indeed compiling Nasal to native code has been suggested a few times already, and so has replacing Nasal altogether or moving it to a separate thread ...):
PS: In theory, we /might/ be able to get away with running Nasal's GC concurrently with OSG's culling - since culling the scene graph is essentially "the same thing" as reaping in the GC, i.e. it's all about traversing a graph/tree structure to decide which elements are relevant/irrelelvant (visible vs. referenced) - at that point, we would run the GC more frequently obviously, but that way, the amount of total work should go down in comparison, because there would be much less of a chance for too much work to accumulate in between two frames; Richard has done some experiments related to running parts of the GC interleaved with OSG. And a couple of years ago it was Anders who came up with a patch to make the GC threaded - the real issue is, it's a mark/sweep collector which isn't incremental/generational, and Anders' patch showed up roughly at the same time as the Canvas system got introduced, which all of a sudden added a ton of Nasal ghosts for things like Canvas (OSG) data structures - basically tying Nasal and OSG together, which is kinda unfortunate admittedly:
http://wiki.flightgear.org/How_the_Nasal_GC_works