First off - I do enjoy Chai script, the language itself is easy, and the binding are refreshing compared with with Lua and others. However the build times do seem to take a big hit (regardless of Stdlib), when compared to Lua/Angelscript etc. Is their anyway to speed this up? I’m guessing this is due to its header (and possibly template) nature, so possibly not.

I’m going to go ahead and respond here and make it a pinned topic. This is by far the biggest comment I get from users.

Things to consider regarding ChaiScript build performance.

As of ~February of 2015 any increase in build times is considered a regression. It is something that is being actively considered. The 5.7.1 release of ChaiScript decreased build times across the board. At the time of writing this, MSVC 2015 is much faster build times than either clang or gcc.

ChaiScript is a header-only library. This means that every time you compile a project using it you are compiling an entire scripting language and all of its supporting libraries. Do you know of any other computer language that compiles in a minute or less?

Does being header only make sense? Maybe. It makes ChaiScript very easy to include in your project. Most of ChaiScript is lots and lots of C++ template magic. Even if we had a compiled portion of it (which we do, it’s the chaiscript_stdlib, actually using ChaiScript in your application asks a lot of the compiler.

Regarding chaiscript_stdlib

At runtime, if not explicitly provided with its runtime library, ChaiScript attempts to find a dll/so that contains its standard library.

This is the difference between the basic and compiled in examples. The first looks for the chaiscript dll, the second does not.

Critical Note: If you are using the “basic” example you must provide chaiscript with a build of the stdlib that PERFECTLY matches every compile option as the rest of your project.

For this reason we do not recommend actually using the loadable stdlib feature

Instead we recommend that you use the feature to break up how ChaiScript is compiled and constructed inside of your project.

What To Do?

Split up the compilation of ChaiScript into 3 basic parts:

The construction of the ChaiScript object itself

The construction of the ChaiScript StdLib

The construction of your application’s specific bindings

A demonstration of how to do this, along with code examples is available in the ChaiScript “Spiced” game engine:

45 seconds for a small example, is a huge amount of time to wait for compiled results. It goes from “almost instant feedback” to “just long enough to lose your train of thought.”

Is this time going to rapidly scale with project complexity?

Is there any way to reduce the time? I don’t care about a DLL mismatch when I’m developing. I’m at 40 seconds.

Are there future plans to try to significantly reduce build time or just hold it as-is?

I appreciate your library and work. But I’m trying to evaluate possible scripting options, and this basically means my current computer is worthless for trying to develop a program and get feedback with any kind of urgency.

Thank you for your reply. I’m using a mostly recent build of GCC. I know the c++11/gnu++11 flag slows compiling down significantly on any project. But when I hit 40 seconds on the example code I thought it crashed the first time.

I did watch most of the video and looked at the recommendations but maybe I missing something? From what I understand, the core idea is to just split it up so that you only recompile sections of the library and not the entire thing each time. But then you’re imposing a certain structural constraint on the application layout and still hitting those compile times any time that particular object file changes. And the video mentions clang getting much faster but switching compilers is also a bit of an intrusive project-level change…

Perhaps, I’m missing something important–I’m brand new to the library. I’m very impressed with the functionality… just surprised at the compile time.

It’s important to remember that you are compiling an entire language and all of its required support functions. I’m just suggesting that you choose to not compile the entire system with each change to your application, by splitting it up.

The proposed layout does suggest adding 2 cpp files to your project. If you lay it out like suggested 1 of those files will virtually never change. It only changes if you do a clean build of your project. The 2nd file changes only when you expose additional functions to ChaiScript.

Clang is MUCH faster compiling ChaiScript, and MSVC is faster yet. GCC is by far the slowest.

There are supposedly some tricks for getting heavily templated code to compile faster, but I’ve not managed to get any of them to work. In general I’ve just been trying to make the code more and more simple and faster to compile in general.

Also, if you are doing optimized builds for each run, those are much slower yet. Debug builds should be much faster.

Having exerimented with ChaiScript in an embedded environment I’m in love with the language and the ease of bonding with C++ internals, but compile times are a problem, and built binary size an even bigger one (I’m guessing they’re largely related.)

Do you have an intro material on how ChaiScript works internally? I have no idea how much can be done, and even less on how much I myself can contribute, but I’m definitely willing to put in some time towards improving this if there’s a reasonable chance my contribution can be valuable.

I’ve spent much of the last two days looking at this again. The best way to start to get a handle on it is to use nm on Linux to get a dump of all of the symbols to see where the compiler is spending its time.

I’ve tried commenting out and rearranging large chunks of template instantiations with some impact, to try and see where to focus my time. Most of these attempts have virtually no impact at all on release builds, and some moderate impact on debug builds.

Your best option, if you want to try to help, would be to use Templight http://plc.inf.elte.hu/templight/ to try and figure out exactly where the compiler is spending its time. I haven’t done that in a while myself.

Indeed, if you can run templight against the build and post the results here, that would be great.

In theory I love templight, but in practice we haven’t gotten along very well (as in completely failed to build it.). I’ll give it a try though.

My uneducated gut feeling after trying a few of my favourite tricks (shaving only single digit percent from the results of nm) is that more drastic changes are needed to make any substantial improval. I’ll see what I can do. Hours will be put in, time permitting, results may or may not be disappointing.

It made a slight affect on compile time, but I think I’m going to abandon the branch. I used the “type inside of a lambda” trick to reduce the symbol table sizes and eliminated all calls to a handful of different helper functions. I really expected it to have more impact.

I’ve also already eliminated all recursive templates in previous rounds of doing these types of improvements.

I’ve noticed little things, like the simple appearance of make_shared<> in code can have an impact, so I just committed a change to develop that reduces some of those templates.

At runtime, if not explicitly provided with its runtime library, ChaiScript attempts to find a dll/so that contains its standard library.

This is the difference between the basic and compiled in examples. The first looks for the chaiscript dll, the second does not.

Perhaps these recommendations (and examples) should be revisited? It seems like the latest version of ChaiScript always creates the StdLib (rather than searching for a dll/so). And now, if you wanted to create a “compiled in” version where you explicitly define StdLib (e.g. in a separately compiled file), it seems you’d need to instantiate the parent class ChaiScript_Basic rather than ChaiScript, which does not allow for specifying a StdLib. Is this still a recommended thing to do?