yeah, but Thorsten is right - Nasal is only one potential culprit, and even if you should identify this to be the case here - you would still want to try different combinations of startup/runtime settings to ensure that this is generally the problem, and not some issue specific to a single airport/location or aircraft.
Also, we have patches to help identify problematic Nasal callbacks, i.e. in terms of dumping the GC pressure to the console (or logging it to a property), so that before/after metrics can be gathered, including the run-time of the GC, and the number of recurring allocations - e.g. temporary stuff.
But it makes only sense to explore all this, once you have confirmed that it is Nasal contributing to the lag you are seeing - like Thorsten said, there's a plethora of other potential factors, with Nasal being one of the most likely candidates, but certainly not the only one.
In general, it would make sense for us to expose these statistics and metrics at the property tree level, so that people can directly open a dialog and look at such Nasal related numbers (number of objects, references and frequency/duration of GC invocations, but also Nasal callbacks/modules contributing to GC pressure).
That would enable people to provide much more accurate data when posting bug reports - analogous to how the help/about dialog displays OpenGL/graphics related info.
However, the "no Nasal environment" mentioned by Thorsten above is an imaginary thing - as long as you don't exclude $FG_ROOT/Nasal entirely but also any $FG_AIRCRAFT related scripts that may be invoked - which frankly is a complicated issue, and problematic approach.
And as far as I am aware, I am the only one to succeed at coming up with a fgfs main loop without any Nasal running at all - which was necessary for being able to initialize Nasal much earlier - decoupled from the conventional main loop:
http://wiki.flightgear.org/Initializing_Nasal_earlyThis kind of thing would make it possible to start up FG with Nasal disabled at the C++ level, so that the GC
cannot run - and it would still be possible to use Nasal for startup-analogous to how rc.d boot scripts work on *nix, but don't have any runtime footprint once the corresponding run-level is reached.
In other words, you could tell people to start up fgfs with --disable-nasal and ask them if they're still seeing the same issues or not