> For the time being, we'll have to live with this. We should just be > aware, that introducing too complex data structures and too > heavy/complex computations in Nasal isn't a good idea. Even when their > average execution time looks ok, they will eventually trigger noticeable > frame rate jitters. The larger the data structures get, the longer the > jitter. The more heavy the computation gets, the more often the garbage > collector has to run, the more often the jitter happens...
That seems to be very system dependent. I am running extensive Nasal computations, but I get the hardest framerate hits from the shaders - I can't use the terrain effect at all since it cuts my framerate from 70 to 10 if I fly over the wrong terrain type - way more troublesome than a short drop from 70 to ~55 when Nasal cleans up. > So, it's still good to implement heavy stuff and common instruments in > our FG core (C++), and use Nasal mainly for aircraft-specific animations > etc. Though that may not be the direction our project is heading to > right now... Since I don't follow the 'rule' by coding 10.000+ lines in Nasal, I suppose that is partially thrown into my direction. From where I stand, there are good reasons to use Nasal - first of all the userbase which regularly compiles their own code is small, whereas people do install addon packages - so I get a lot more feedback and test results. Second that one usually can't really crash the whole system from Nasal. Third, it's very easy to quickly try something and very maintenance-friendly. Fourth, you can actually start developing something without knowing how the core code ties together - which I suppose takes a lot of time to learn. And so on. The argument against that is essentially that C++ is faster than Nasal - which, everything else being equal, is certainly correct. But highly specialized Nasal code written for a particular problem outperforms general purpose C++ code - I've given several examples in the past. If someone were e.g. to add movement to Nasal spawned models by adding a velocity property, I'm not sure it would outperform my Nasal quadtree-sorted adaptive range code which priorizes movement for things actually inside the field of view. Of course, if you'd hard-code that specialized algorithm, it would be faster than the Nasal version - but then you couldn't apply it to other problems any more. But if people feel that things inside e.g. the Local Weather package (or somewhere else) should be ported from Nasal to C++ - by all means do so, don't just complain :-) You have the Nasal code available, I for one am entirely willing to explain to anyone who wants to hard-code something what certain things do and how things tie together - I'm just not going to do it myself. Cheers, * Thorsten ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
