20,741
edits
m (→Performance / Optimizations: extending APIs and diagnostics to optionally track potential rogue scripts and problematic constructs) |
|||
Line 129: | Line 129: | ||
= Performance / Optimizations = | = Performance / Optimizations = | ||
* a bunch of performance issues were reported [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg36668.html] to be related to: | |||
** accidentally registering listeners/callbacks twice without noticing (or even more often) | |||
** never freeing timers/listeners, i.e. we could make sure that issue a warning if a listener's ghost is GC'ed while the listener is still active, because there's then now way to clean up the listener | |||
** aircraft/addon scripts setting up listeners and timers without registering a /sim/signals/reset handler that handles cleanup | |||
** always letting timers run at frame rate | |||
* Hooray: look into adapting the existing GC scheme to support multiple generations - which is a straightforward optimizations even without being a GC expert, it basically boils down to having a single typedef enum {GC_GEN0, GC_GEN1} GENERATION; in code.h and then changing all places in $SG_NASAL to use the GC_GEN0 pool by default, i.e. instead of having &globals->pools[type]; - we would have &globals->pools[GC_GEN0][type]; for starters - the GC manager would then by default only mark/reap the GEN0 (nursery, young generation), promote any objects that survived the GC phase to GEN1, and only ever mark/reap GEN1 if GEN0 has to be resized (start off with reasonably sized generations, based on real stats - e.g. GEN0 16 MB and GEN1 32MB). {{Not done}} | * Hooray: look into adapting the existing GC scheme to support multiple generations - which is a straightforward optimizations even without being a GC expert, it basically boils down to having a single typedef enum {GC_GEN0, GC_GEN1} GENERATION; in code.h and then changing all places in $SG_NASAL to use the GC_GEN0 pool by default, i.e. instead of having &globals->pools[type]; - we would have &globals->pools[GC_GEN0][type]; for starters - the GC manager would then by default only mark/reap the GEN0 (nursery, young generation), promote any objects that survived the GC phase to GEN1, and only ever mark/reap GEN1 if GEN0 has to be resized (start off with reasonably sized generations, based on real stats - e.g. GEN0 16 MB and GEN1 32MB). {{Not done}} | ||
** http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Generational_GC_.28ephemeral_GC.29 | ** http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Generational_GC_.28ephemeral_GC.29 |