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*);

and the loading and saving can be like this:

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

although that was something like a simple theory, and that was a suggestion

I really think that "speed issue" is a no-issue.

The only negative thing I have to say about Angelscript is that for some reason it compiles to a... huge... binary. But that may very well be the compiler's fault (I'm not sure, sometimes GCC includes ridiculous amounts of data, including RTTI and string names of all classes, if you only throw one exception somewhere in the program... it includes RTTI even for classes that you don't throw or even use at all -- maybe that's just the reason here, too).

Angelscript is, however, intuitive, and integrates nicely, and it gives me something that "looks like C++", mostly. What else do I need?

I am not trying to calculage the 20,000th fibonacci number or the 2 millionth digit of PI in Angelscript, nor do I want to write a raytracer in it. What I want, what I need, is the ability to write a script that lets me customize a NPC's behavior. Which changes some state machine, and maybe calls one or two native C++ functions. What I need is a function that runs some logic when the user presses a button where whatever happens can be customized. And I need that without writing my own script language, without getting used to a new, weird syntax, and without having to recompile the executable every time.

Angelscript does all that. Yes, Squirrel does all that, too, and its binary is a third the size (why, I wouldn't know)... but it is sooooooooo darn painful to do the bindings. I don't like pain.

So, running that logic when a button is pressed takes 0.8 microseconds. With Lua, it would run in 0.2 microseconds. Who cares?

I have never benchmarked Python against Angelscript, but my estimate is Python is at least about twice as slow. Does it matter? Apparently it's still fast enough to drive the entire GUI in Blender 3D.

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.

With the JIT enabled, Angelscript is really fast. I could even use it for real time audio processing. It is about 5 times slower than C++ in such a scenario, which is impressive for a scripting language!

As for LUA, if you can cope with its syntax, just use it. But IMHO Angelscript is much easier to use - be it for its syntax, C++ integration or features.

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. :)

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