How much faster do you think AngelScript should be? 10% faster? 50% faster? Twice as fast? 10 times faster? :)

If you have any suggestions for how to optimize the code I would be very interested in hearing that.

It's so funny (but also frustrating) when AngelScript is compared with Lua. I would love to have the resources that the team behind Lua has. You do know that Lua was invented back in 1993 by a team at a university and is still maintained by that same university (PUC-Rio in Brazil) and has actual investment money behind it? AngelScript on the other hand was invented by me in 2003 and is maintained by me with zero investment money? I've been working on AngelScript on my spare time for 13,5 years now. While some of the code has been contributed by community members it is practically a work done by a one-man-team.

All things considered I think AngelScript is comparing quite well to other scripting libraries out there (including Lua).

PS. Have you tried Blind Mind's JIT compiler for AngelScript? Perhaps it will allow you to get the performance you want.

hi,

AngelScript is easy to add to an application, and it has a syntax similar to C++, which i love and i'll use it
i've only showed my tests that i've done and the result, nothing else
at least when i've tryed the AngelScript with that JIT Compiler, it crashed the application
anyway, AngelScript is my favorite scripting language, although lua is faster (i appriciate your grate work that you are doing on AngelScript)
anyway, sorry

and a suggestion for byte-code optimization:
in my idea, it would be good to be able to add callbacks for byte-code optimization for example like this:

void asIScriptEngine::addByteCodeOptimizationCallback(asByteCodeLoadOptimizeCallback*, asByteCodeSaveOptimizeCallback*);

void (asByteCodeLoadOptimizeCallback*) (asEBCInstr instruction, asDWORD* byteCode);
void (asByteCodeSaveOptimizeCallback*) (asEBCInstr instruction, asDWORD* byteCode);

at least when i've tryed the AngelScript with that JIT Compiler, it crashed the application

If you want performance this is really the way to go. If I were you, I'd give it another try. Though I haven't used the JIT compiler myself, others are using it, so I'm sure it is working. The crash you experienced is probably something simple to fix once you do some investigation.

anyway, sorry

No need to apologize. :)

in my idea, it would be good to be able to add callbacks for byte-code optimization for example like this:

Thanks for the suggestion. Though I don't really see that a callback for byte-code optimization would be of any use. The compiler already does bytecode optimization, if an application developer has an idea for making even more optimizations then he should preferably do that within the library itself (and hopefully contribute the improvement back to me so it can be shared with others too).

The only negative thing I have to say about Angelscript is that for some reason it compiles to a... huge... binary.

How big is 'huge'? A while back I experimented with different compiler options to see just how much Angelscript added to the binary size. The library (VM + compiler) is around 700KB. Is that 'huge'?

Though I can't be sure, I believe Angelscript compiles to a larger binary than with Lua or Squirrel because the compiler is much more complex, and the logic for holding the bindings, making native calls, etc, is also more complex (a trade-off for making it easy to bind). If I'm not mistaken, Python's binary size is even bigger. If you want small binary size you should take a look at Pawn, which was as far as I understood was designed specifically to be tiny.

How big is 'huge'? A while back I experimented with different compiler options to see just how much Angelscript added to the binary size. The library (VM + compiler) is around 700KB. Is that 'huge'?

I get a 1750kB file for a no-debug static lib (whereas Squirrel, which I happen to have compiled for another project, is a mere 431 kB).

A program that looks like this:

int main() { auto scriptengine = asCreateScriptEngine(ANGELSCRIPT_VERSION); return 0; }
...gives me a 1MB executable (stripped).

But don't get me wrong, I didn't mean to say Angelscript was bad. When saying "the only bad thing I can say about Angelscript", that was rather meant to indicate that I'm actually pretty happy with it, in particular with its speed (which was the "issue" in this thread) but also with the ease of use.

Somewhat bigger executable than I would ideally like, well OK, ... but you know, look at the size of some executables, and how much rubbish they load on top of that in DLLs! In that light, what's a megabyte.

Some office program from a well-known mainstream manufacturer which doesn't do anything but... text... (and doesn't even do it well) is so darn huge it wouldn't even run on a computer that is slightly older than 5-6 years. :)

@samoth, you can do some optimization checks with your compiler to reduce the size

for example, -o3 optimizes your code a little for you

and, something intresting:

i've compiled AngelScript without jit compiler and only with jit instructions and with bytecode optimization into the app, it executed the scripts faster, (i didn't attach a jit compiler into it)

this script:

void main()
{
InitTimer();
for(auto i=-100000;i<=100000;i++)
{
cout<<i;
}
cout<<"\nexecution success\n";
cout<<"the execution took "+GetTime()+" seconds\n";
}

it took 38.2324 seconds which is grate