What you describe is called "frame-spacing" - i.e. the amount of time it takes to render a single frame, see ThorstenB's explanation here:
http://wiki.flightgear.org/Howto:Use_the_system_monitorThorstenB wrote: imagine a system producing 100 frames in 0.5 seconds, then blocking completely for another 0.5 seconds: The fps display would still show "100fps", which seems great. But the 0.5 second stutter cause the visual performance to be terrible.
When evaluating simulation performance, don't get fooled by the frame rate. What's really important to us is the "worst case frame latency". Even if the system is producing a huge average of 100 frames per second, it can still look absolutely crappy, if only a single frame took more than 20-30ms, since that's immediately visible to the human eye. So, we're building a real-time system here, and 20-30ms is our timing constraint.
That's why it is preferable to display "(worst-case) frame spacing" instead of fps (View => Display Options => Show frame spacing). The frame spacing for the previous example would show "500ms", while a system producing 100 frames with perfectly even spacing would show "10ms".
So, frame spacing is a much better property to judge visual quality than just watching fps.
To see if it's related to Nasal callbacks, you only need to apply a simple patch I once posted here, which wraps each callback into SGTimeStamp calls, so that you can easily "time" each callback - and show "hot spots" that take more than several ms. You'll only get the file name and line number where the callback was registered though.
If it indeed Nasal callbacks that coincide with the stuttering, you should check if it's due to the Nasal code itself or due to the GC. ThorstenB once posted a patch doing this, I think it was ~30 lines.
Obviously, you need to be able to build from source, but at least, this can tell you 1) if the issue is related to Nasal callbacks, 2) if it's GC related or 3) if it's related to extension functions or "rogue" code.
To see if it's due to the positioned update, you only need to add two systime() calls to MapStructure (I think we might be even doing this somewhere?) - that will tell you if it's due to the spatial search.
It would be good to know what the issue is so that we can prioritize optimizing things - even though it seems that anything related to the GC is unlikely to be very popular