Ok, I'll wait, though it will be difficult. I'm extremely curious to see your code. I'm almost jumping up and down like a child waiting for a present [wink].

I don't think we have to worry about compatibility between different versions of the library. It's enough that the original script code is compatible.

My goals are all of those. You can read the original goals here: http://www.angelcode.com/angelscript/goals.asp. They may have changed slightly during this last year, but they should be pretty accurate.

If I have to prioritize the goals it would be in the following order:

1. stability
2. ease-of-use
3. features
4. speed

Stability goes first, because a library that is not stable will not be used. Ease-of-use goes next, because it's in my nature to always think about how I can make things easier to use.

Features are important. The library will have all the necessary features that cannot be made an add-on. For example the library will never have a built-in xml parser because it could easily be made as a registered class, but the library will have native support for co-routines as this is not something that can easily be made externally.

Of these four speed is the least important. This is not to say that I won't make the library as fast as it can possibly be, it's just that if I have to choose between a necessary feature and speed I will choose the feature.

With your help I think the speed part at least should be mostly taken care of. I think only native code will be able to compete with the speed of AngelScript after you and I have finished optimizing the library. With your current changes I believe that AngelScript is very close to being the fastest scripting library around. (Does it show that I'm excited about the optimizations you made? [wink])

Did I give the right answer to win you over, i.e. will you use AngelScript in your project? [wink]

Regards,
Andreas

Personally I haven't done any tests with any other scripting library. I suppose I should but I simply don't have the time to do so.

I'm aware that I might be called a liar for saying that AngelScript will be one of the fastest scripting libraries, but I only say what I believe. If someone shows to me that another scripting library is faster it will only make me work extra hard to make my library even faster. That is what spurred this latest optimization of AngelScript.

RCL told me that Lua was almost 2 times as fast as AngelScript. I knew that AngelScript could theoretically be faster than Lua so I set about optimizing it, and managed to make my library almost 2 times faster. Then RCL came back and told me that he had made a mistake and Lua actually wasn't so much faster as he had originally stated, it was more like 50% faster. Which was fortunate for me because it means that AngelScript should now be faster than Lua.

Of course with the new VM that Lioric has written for AngelScript, my library should be way faster than Lua is and might even compete with other scripting languages that have JIT compilation.

You say that you are coming closer to being able to use AngelScript in your project. May I ask what is keeping you from using it already?

Rain dog:

Well, that is certainly a valid reason not to use AS [wink]

Lioric:

I know what you mean. It's difficult to say what to prioritize in such a generic way. There are some features that are more important than speed, and others that are less important than speed.

If there is a feature that I want to add to the library that requires sacrificing a lot of speed I will make sure that it is made optional. That way each user can choose what to prioritize themselves.

I will run the VM through all of my test cases, and if there is any problem I'll try to fix it. If I need help fixing it I will contact you, ok?