Jump to content
  • Advertisement
Sign in to follow this  
loboWu

Terrible performance deficiency on asCRestore

This topic is 2173 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

Hi:
I am using 2.21.0 for a long while.
When I start to upgrade to 2.24.0a or the latest svn,
I found a performance issue.

Lets see the code.

[source lang="cpp"]In 2.21.0
asCScriptFunction *asCRestore::ReadFunction(bool addToModule, bool addToEngine)
{
...........
if( func->funcType == asFUNC_SCRIPT )
{
engine->gc.AddScriptObjectToGC(func, &engine->functionBehaviours);

count = ReadEncodedUInt();
func->byteCode.Allocate(count, 0);
ReadByteCode(func->byteCode.AddressOf(), count);
...............
}
}

It allocate just one time for the function bytecode.[/source]

But In 2.24.0a~
[source lang="cpp"]void asCReader::ReadByteCode(asCScriptFunction *func)
{
// Read number of instructions
asUINT numInstructions = ReadEncodedUInt();

// Reserve some space for the instructions
func->byteCode.Allocate(numInstructions, 0);

asUINT pos = 0;
while( numInstructions ) //in my env, this could be 400K or more
{
asBYTE b;
ReadData(&b, 1);

// Allocate the space for the instruction
asUINT len = asBCTypeSize[asBCInfo.type];
func->byteCode.SetLength(func->byteCode.GetLength() + len); //too much allocate and memory copy here
asDWORD *bc = func->byteCode.AddressOf() + pos;
pos += len;
................
.................
}[/source]

In my enviroment, I use angelscript to implement a huge database processor.
So in the most time, there are huge arrays.

For example, there is a array initial function which produce 400K bytecode instructions.
It take a long long time to restore bytecode.
Whould you help me to solve this problem?
Thanks,

Lobo Wu Edited by loboWu

Share this post


Link to post
Share on other sites
Advertisement
A single function with 400K instructions? WOW!! :)

I'll look into what can be done to improve the loading speed for something like this. I would obviously have to improve the prediction of the final bytecode size to avoid lots of resizing.

Are you seeing other bottlenecks, than just the resizing of the bytecode buffer?

Share this post


Link to post
Share on other sites
In 2.21.0 the only visible bottleneck is the Garbage Collection.

GarbageCollect(asGC_FULL_CYCLE ) take very long time ( about 15 seconds)

So I use
GarbageCollect(asGC_FULL_CYCLE | asGC_DESTROY_GARBAGE)
and call GarbageCollect(asGC_ONE_STEP) at stated periods.

The mostly parts are excellent. I use angelscript to implemnt my SDK.
And twenty engineers use it to achieve lots of work.
We have preprocessor, compiler, editer, events, object manager .....
Everything is just fine and isn't over designing.
Angelscript is a good library.

By the way, would it be possible to downsize the bytecode?
I use gzip to compress my bytecode files, but there are still too large (totally ~ 1G)

Share this post


Link to post
Share on other sites
That the GC takes time to run a full cycle is natural and I really don't see how to improve this. Still, this is why I've implemented it with the incremental algorithm so you can do what you did, i.e. spread out the execution so it won't impact the performance.

I'll look into the bytecode size, but I don't have any immediate ideas on how to reduce the size any further.

What is the size of the original script code if your compiled bytecode takes up 1GB (compressed)?

Share this post


Link to post
Share on other sites
[sub]One model: (totally 30 ~ models)[/sub]
[sub]scripts size 293 MB compressed bytecodes 65 MB[/sub]

Share this post


Link to post
Share on other sites
The loading of the bytecode should now be restored to the performance it was before 2.23.0. I've checked in these changes in revision 1389.

Regards,
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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!