Hooray wrote in Tue Nov 24, 2015 3:25 pm:I am not too optimistic regarding GC patches, I mean there are a bunch of related patches circulating around, including even stuff that core developers like ThorstenB and AndersG came up with, and still nobody committed those, despite them being useful to experiment with the GC.
AndersG wrote in Tue Nov 24, 2015 4:07 pm:There were some serious issues with my patch - namely that the destruction of some C++ side FG objects kept alive by Nasal references must not be invoked on a different thread. I didn't see the crashes, but they appeared for people using Canvas heavy aircraft.
Hooray wrote in Tue Nov 24, 2015 1:24 pm:Some of your results are a little odd, i.e. are not yet interpreted properly - but the underlying data/findings are interesting.
AndersG wrote in Tue Nov 24, 2015 4:07 pm:2. Per frame work (including Nasal timer 0 loops) will increase with the frame rate. Going from 20 fps to 2000 fps will thus increase this load by two orders of magnitude.
hamzaalloush wrote in Tue Nov 24, 2015 10:12 pm:AndersG wrote in Tue Nov 24, 2015 4:07 pm:2. Per frame work (including Nasal timer 0 loops) will increase with the frame rate. Going from 20 fps to 2000 fps will thus increase this load by two orders of magnitude.
Where in Flight Gear can i evaluate this load increase, is it number of iteration of the Nasal sub-system for instance? actually, do Nasal timer loops have an actual footprint?
Hooray wrote in Tue Nov 24, 2015 10:30 pm:Basically, imagine it like a toolbox with plenty of "useful" tools in it (Nasal modules) - as long as everything is in it, it's obviously easily available, too - but there will also be an increased cost, i.e. weight to carry the toolbox.
Thus, it does not matter if you are using Canvas or not: the corresponding modules will be made available to Nasal, which does increase the "search space" (volume) that the GC function has to traverse/process.
Hooray wrote in Tue Nov 24, 2015 10:30 pm:The solution for that, I mentioned in the other thread - including C++ patches, it's trivial actually: instead of adding stuff in a hard-coded fashion using postinit() hacks, the corresponding bind() and unbind() methods of the underlying SGSubsystem are used - which were introduced for tied properties, but can be used for this purpose, because when the system is added/removed, those methods will be invoked by the subsystem manager.
void SGSubsystem::postinit ( ) [virtual]
Initialize parts that depend on other subsystems having been initialized.
This method should set up all parts that depend on other subsystems. One example is the scripting/Nasal subsystem, which is initialized last. So, if a subsystem wants to execute Nasal code in subsystem-specific configuration files, it has to do that in its postinit() method.
Basically, people should not be using callbacks that are invoked once per frame (and in fact, some code we've seen was registered to be invoked several times per frame!).
Users browsing this forum: No registered users and 0 guests