Heres a core issue of Performance (With some mind blowing testing)

GDevelop general
1

I am reusing this post because i feel like im starting to spam post about this and i want it to just be over.

Im also deleting the video on small tips for improving performance because due to recent testing, im happy to say that im full of it and very much wrong.

GDevelop can handle a lot more then people give it credit for and the video bellow is the proof.

The big performance issue iv been dealing with have all been because of some Extension of Behaviour, never because of anything from the core engine.

This time i think is no difference, iv been falling for the whole “this is very bad for performance, dont let it run too often” thing… when in reality, the real performance draining vampire was some event from a specific behaviour or extension.

In this video ill show you all the hours of work iv been putting into testing and trying to bring one of my events down as much as possible.

As i was working on it, and doing all that i could to “lock” it so that it would only run on very specific occasions, or even stopping it from working completly, i saw the performance get worse and worse…

When i went back to using no behaviours, and just using the basic events that come with GDevelop, even if they ran all the time, the performance dropped from an all time high of 0.60ms, down to 0.03ms…

And this was using something people consider heave on performance like RayCast!

Having RayCast running all the time, from multiple sources at the same time, every frame… was vastly superior to have it run only one time, while one screen, but have it “locked” behing an “event” from the InOnScreen Behaviour…

You can make up your own minds about it

2

Just reused this post and edited the whole thing so i dont spam post… and i felt like it was wrong anyways.

Hope this new one can help people with their performance issue!

3

I watched the first 5 minutes of your video and note that you haven’t shown that raycasting from everything all the time is more performant than raycasting from a select numbr of positions/objects. What you’ve indicated is that checking whether an object is on screen is less performant that checking if an object is a set distance away.

4

Think you must of missunderstood something…

The events with “isOnScreen” was triggering the Lava tile to start RayCasting.
That one was the worst performance.

Then i did the same thing but with check for distance, and if close enough then trigger the Lava to start RayCast, this was much better by a long mile, not using the behaviour.

Then i even tested just letting all the Lava tiles RayCast and it was still miles better then using the “isOnScreen” behaviour to only trigger the single, one, specific, lava time that was check as “On Screen”.

I know i dont explain myself well some times, but i thought that much was obvious…

Think you got things backwards there.

5

Oh I understood that perfectly. What I was gettting at was that this quote:

is not correct. From the first 5 minutes of video, that’s not what I witnessed. Instead, it was a comparison between the behaviour and an efficient mathematical equation. Running ray casts from every object all the time can become processor intensive and affect performance.


That’s a tad condescending.

6

How about you watch more then 5mins.

Theres more then one test.

The first one was using 2 locking systems, one with IsOnScreen and the other with distance and the difference between them.

Using the behaviour was way worse…

Then i kept testing and to make my point across, I TOOK OFF THE DISTANCE CHECK and let the RayCast run EVERY FRAME FROM EVERY TILE.

And IT WAS STILL BETTER than using the Behaviour.

Im sorry if this is comming across as rude, but its annoying when after all this testing, after all the video proof that Events have nothing to do with the massive increase in lag… BUT that even within that some behaviours are much heavier then just using regular evemt… You watch a little bit, didnt bother finishing to get all the facts and then try to call me out on something that im showing EXACTLY as i said.

Watch the damn video, i know i drag along some times and talk too much, but if you dont like reading or watching then dont talk as if you have all the information, because you dont.

7

It is a bit much to expect people to watch a 30 minute video that can be concisely summed into something which can be read in under a minute. I have demonstrated this with a test below.

I understand it’s frustrating to have to spend so much time only to discover the bottleneck is something unexpected. Take a breath and a metaphorical step back from the situation to view it from a distance.

Your initial post is rather verbose and confusing. I had to reread it a number of times to understand what you are getting at, mainly because the raycast reference is a big distracting red herring, and irrelevant to the issue (raycasts, btw, can be a performance hog if it’s run too often per frame).


My example of a more concise test and results:

Here are my test events:

image
image962Ă—284 22.4 KB

And here are the test results. The lines starting with “1 …” are the milliseconds it took to execute 100,000 distance tests. The lines starting with "2 …"are the milliseconds it took to execute 100,000 OnScreen behaviour tests.

image

From this, it can be seen that the OnScreen behaviour is around 10 times slower than an efficient mathematical distance calculation


And that’s all that needed to be done.

2 Likes
8

Oh, and to answer your question from the video. I believe the order that the objects are listed in the debugger is the order in which they are added to the scene objects panel in the scene editor.

Yes, it’s frustrating that there’s no order by or search option, especially when you have a large number of objects. Maybe put it forwards as a feature request?

9

Thanks for taking the time to further prove my point when it came to the InOnScreen Behavior.

The reason the videos of me testing stuff are so long is because of all the randomness of the actual engine performance, im trying to document how it goes all over the place, so basicly its an all in one.

Even tho i like your test better since its far more conclusive and analitical, theres also the issue of it possibly missing something random that might be causing problems.

Thats why i test and retest and record the whole thing, theres stuff that happens one moment and not the next.

Because i recorde the whole thing your able to see the engine performance drop out of no where and then fix itself, you can see the whole process and not just a number.

Back the RayCast, i did show how having it going every single frame checking for your position was miles better than using the behavior, i wasent being miss leading, i said it that way because everyone makes a fuss about these things being expensive to run often but then they completly miss the fact that some behaviors, like the IsOnScreen, are crazy hogging their performance.

With all due respect to who ever made InOnScreen, that behavior should be removed, it serves no purpose, you can do the very same thing with a distance check and it will be way more efficiant.

Someone who has no idea about this, like me, might be using a bunch of it thinking its harmless since its such a simple behavior, and have their entire project bogged down because of it.

Also… english isnt my first language, some times its hard to express myself, im also blind, as in literally legally blind with less than 1/10 of vision, typing long posts is hard for me thats why i like using the videos.

3 Likes