These are improvements to our engine that were discovered by profiling 0.a.d. I'm creating a meta bug for it, to have a better overview what changes are required for 0.a.d. to have proper performance. So we can track them better. This doesn't mean we change our engine to better suit 0.a.d., but fix performance bugs that are present in 0.a.d. and could also hurt execution in normal browser!

There is an interesting article here about spidermonkey performance in 0 A.D.: http://www.wildfiregames.com/forum/index.php?showtopic=17726 Upgrading from v1.8.5 to v27 improved the speed only on random maps generation, while there are slowdown elsewhere.

Could that be caused by the size of the functions? We had a similar issue from people looking at doing a video decoder in JS, and one of their function was too large to be compiled with IonMonkey. I think this is likely to be a common issue since the removal of JaegerMonkey, as JM had chunk-compilation, and Ion does not have any substitute for it yet. Note that this should be solved if the JS engine is compiled with a thread-safe build, in which case we have a compilation thread which will compile large functions. Can we print a warning message if a function cannot be compiled because of its size?

I've done a lot of testing with different IONFLAGS enabled. The "Aborts" flag prints a message if parallel compilation isn't enabled and scripts don't get compiled because they are too large. Parallel compilation is enabled and there aren't any abort messages related to the script size left. I really spent a lot of time analyzing the issue and H4writer compiled the game and had a look at it too. Some of the issues we discovered are linked to this bug, but we didn't find a single problem that causes everything to be so much slower than expected. There's quite a long history of things we've tried here: http://www.wildfiregames.com/forum/index.php?showtopic=17289 I would really like to turn the performance aspect of my work for the upgrade into a success. At the moment I doubt this is possible.

So far it looks like v31 will not improve performance (or only a small bit). The previous measurements for the unmodified v31 could not be confirmed unfortunately and are probably not accurate (too small number of tests, too small difference). However, I've repeated the measurements with a lot of care and much more repetitions than last time and I'm confident about the following conclusion. Most of the performance is lost because of JIT code being garbage collected. In my measurement I got an improvement of approximately 13-14% by setting the flag "alwaysPreserveCode" in vm/Runtime.cpp from false to true. Also keep in mind that this improvement is for the total duration of a non-visual replay from which only a part of the time is spent in SpiderMonkey (somewhere between 30% and 70% maybe... would have to check), so the JS execution performance has improved much more than these 13-14%. I know that this has been improved in several patches after the release of v31, so I'm looking forward to testing newer SpiderMonkey versions. This will take a while however, because we first have to switch our build system to C++11 and commit the SpiderMonkey 31 upgrade. Here's a full link to my measurements including details about the setup, standard deviations, distribution of results etc. http://www.wildfiregames.com/forum/index.php?showtopic=18466&page=2#entry298215