Jump to content
  • Advertisement
Sign in to follow this  
GGLucas

[PATCH] Compiler performance improvements

This topic is 2072 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

We recently passed the 6 second mark for compiling all our scripts in the debug build of our game. Waiting 6 seconds every time you want to test out a new change or for checking whether something compiles was getting a pain, so we threw a profiler at the angelscript script compiler to see if there were any bottlenecks we could fix.

Most of our eventual performance improvement came from changing the way we handled/injected shared code, which reduced the amount of compiled code by about half (with a similar speed improvement), but we did find some things that you might be interested in, the biggest being a major speed improvement to keyword tokenization.

Firstly, compiling angelscript with gcc is currently broken, compile-gcc.patch fixes it. asBC_DWORDARG was being used as an lvalue on as_restore.cpp:3975, I changed it to use the same format as the other asBC_*ARG macros so that that's not invalid.

The biggest bottleneck in compilation for us was asCTokenizer::IsKeyWord, which was taking up over 21% of the total compilation time. I changed it from repeated binary string searches on a map to use a lookup table based on the first character - this is tokenizer.patch. It could probably be improved even further by using something like gperf, but since this shot it down to about 1% of the compile time I moved on to other things.

The last patch maps.patch is sort of a mix match of things related to eliminating linear searches from identifier lookups throughout the compiler. Feel free to pick and choose any or none of it, most of this was just us (Andrew Ackermann and me) slapping maps or symbol tables in various places.

Share this post


Link to post
Share on other sites
Advertisement

Thanks a lot. I'll review the patches carefully and incorporate them into the SVN as soon as possible.

 

Regards,

Andreas

Share this post


Link to post
Share on other sites

Wow exciting, I love to hear about optimizations, GCLucas can I ask approximately how many KB or lines of code of Angelscript do you have that it took 6 seconds to compile?

If the load time was 6 seconds, what is it now after these optimizations?

 

Might I recommend that you consider using the release version of your game to test scripts for compile errors? Compile errors should be reported just as well in release as debug mode and asserts can be enabled in release mode if desired.

 

Alternatively, you could also consider loading the last (date modified) saved script first for compiling, This would result in compile errors being found near instantly.

Share this post


Link to post
Share on other sites

GGLucas and I both work on the project that had the (not really very) long compile times. The 6 seconds was in release, and is the compile time for ~1.1MB of scripts. Post-optimization is closer to 1.5 seconds, but some of that is from improvements specific to our use of AngelScript. Debug for me was taking upwards of 28 seconds to compile by comparison.

 

We have tried to use bytecode saving and loading, but it doesn't work with something in our codebase that we've yet to find a solution to.

Share this post


Link to post
Share on other sites


but it doesn't work with something in our codebase that we've yet to find a solution to.

 

What is wrong with you code if they can't save and load?

Share this post


Link to post
Share on other sites

The bytecode saving or loading has a subtle bug with shared code that we've never been able to isolate. It disappears whenever the codebase gets small enough to reasonably test.

Share this post


Link to post
Share on other sites

I've finished incorporating these improvements into the WIP version. (revision 1779).

 

With the improvements I see an average improvement of around 30% in the compilation times. 

 

I didn't include the changes as-is, so when you pick up the new version you'll will not see exactly the code you provided, but you should see that all the improvements you made has made it into the code, and in some cases I made further improvements on top of them.

 

Thanks,

Andreas

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!