I’ve been trying out Gdevelop for the past few days cause it looks like a great open source alternative to a engine im using atm,me and a friend decided to do some performance tests and found events to have a extremely high amount of overhead from just rendering 2000 sprites on screen and looping thru them
What are your events doing? Can you paste them?
Events are directly compiled to JS, which will be basically a loop over the sprites, which should be blazing fast just like manually written JavaScript code.
If you’re using conditions like conditions, things will change quite a bit as they are expensive, more generally anything that involve a lot of objects.
EDIT: More generally, would be cool if you can share the project, screenshots of the events, etc… it’s hard to help if I don’t have much apart from a profiler screenshot 
But again, as events are compiled to JavaScript, the raw performance should be better than anything else. In a real game, event overhead won’t be noticeable, but usage of collision detection, the amount of objects animated, the amount of objects that are moved etc… will be what you have to be careful of.
Thanks for the project, it’s useful
A few things:
-
Code generated for the “for each” might have a useless initialization of an array, which is costly when you have lots of bunnies.
-
For each is actually for special case when you want to distinguish precisely your events for every single object. Here in your benchmark, you’re paying this cost while it’s not needed.
If you’re using conditions, they are iterating directly already on the array of objects. -
Not sure if it’s intended or not, but your event is creating 500 bunnies, and this at every frame.
So if you press Up for one second, and if the game was able to keep up the normal speed, you would end up with 60*500 = 30 000 bunnies.
For your interest, here is the code generated by the for each:
There is a useless initialization of the array (which is creating a complexity of N*N, where N is the number of objects) but apart from this (I’ll check to fix this), you can see that it’s a classic JavaScript loop - the fastest you can actually do And again, it’s unlikely you’ll ever for each of 5000 objects - you’ll be using collision/distance or other conditions that don’t have the penalty of for each.
As another example, consider the “Repeat 500 times”. Here is the generated code:
Basically here the event is a 0 cost abstraction - it’s pure JavaScript, optimized by JIT compilers of browsers 
It’s like a manually written loop (with cumbersome variable names, but that won’t matter ;))
Ahh ok thanks for clearing that up 
,And yes it was intended to create a large amount of bunnys 
i wanted to see how things would stabilize at those numbers,The reason i was doing the for each on 5,000+ objects was to do a small bunny mark benchmark to determine if i should begin getting more familiar with the engine now or wait till later.That’s great to know that it was just a lack of understanding of how the events work tho for the most part xD,Would it be possible to get a bunny mark public project out just to prevent other future adaptors from attempting what i did and jumping to bad conclusions?(4th day testing out Gdevelop)
Well turns out that you did well and there was actually a suboptimal code generation for the “For Each”, so at the end this was very useful 
Even if in “real life”, it’s unlikely that for each is used on so many objects, I’ve fixed the issue for next version so that the cost of running a for each is a simple loop, without extra array copying (so no more N*N complexity).
I’ve tested again, and things are now, as expected going 60 fps even with tons of bunnies:
12500 bunnies, and apart from the editor that is struggling a bit to render the list of objects on the left, the game itself is 60 fps smooth. (In real life again, still avoid so many objects, because the engine will start to slow down when rendering so many things)
If you’re interested, here is the code generated (in the fixed version), for the for each:
A simple loop, so as fast as you can get
Thanks for reporting and uploading the project, that was very helpful!
Glad i looked into it then,But thanks alot! this actually surpassed my expectations that performance improvement really blew my expectations out the water i cant wait to try this out more in depth.
The reason i wanted to test that large amount objects being ran under for each was cause i wanted to test if the engine could handle making a bullet hell type of game where it wouldn’t be a surprise if there are hundreds if not thousands of projectiles on screen or some larger scenes,
Such as rpg or action games that involve things like setting a forest on fire by starting setting 1 tree on fire then it spreads to other trees or large aoe ability’s that would in compass alot of objects
1 Like
Probably the most useful thing I’ve learned so far. Had no idea that For Each was this taxing.
This is actually mind blowing. Is there a way that For Each events can be converted into normal events or does it have to be done manually. Thanks 4ian.
Well actually you can see from my explanation that for each by itself is not taxing, it’s a fairly standard JS loop. What you do inside is another problem. There won’t be any performance change if you transform it to a standard event as long as they do the same thing.
But if you don’t need a for each, it’s safer to use a standard event as they will avoid you to fall in a trap where you’re doing repeated work for each object
I just converted a large number of functions from For Each and did notice a slight performance boost. I might as well convert what I can to save what I can. It’s very minor, but it is something I suppose. I’ll take it where I can get it in the long run.
Thanks much.
1 Like