Performance Experiences

There's never going to be a #3.

You should stick to events. Js would be for corner cases, or if you prefer code.

You have to remember that most of the time the engine will be doing nothing. Which is what you should be striving for in your development anyway.

newt In my current project, the engine is very active, and performance is a major priority.

Are you suggesting that you've done at least moderate testing between events and js, and found that there is no benefit? If so, would you mind giving a bit of insight regarding what that involved?

There's nothing to test, Js will run faster because of the overhead of events.

That doesn't mean it will solve every problem.

If your getting a constant slow down then chances are that js won't be much help. In that case you would need to see if you can change how it works, or try some optimisation.

If you get spikes because of from some mechanic, then Js might help if there are no event optimisations.

I think the real question here is what are the limitations, and how do I tell if I am close to that.

newt thanks for the quick responses.

There's nothing to test, Js will run faster because of the overhead of events.

Do you happen to know what "overhead of events" actually constitutes, even if your knowledge is only related to a specific example?

Also, just a little concerned that our conversation is beginning to distract from the intended discussion. The purpose of this thread is to [hopefully] collect experiences where users have encountered a meaningful difference in performance between using events and JS, regardless of circumstance. As far as I can tell, no such information is available.

Do you happen to know what "overhead of events" actually constitutes, even if your knowledge is only related to a specific example?

Well the runtime is impossible to read now, but I know from past experience that it has a bit of an abstraction layer as everything has to be looked up sort of like a function. That's the nature of an engine not written from custom code.

The code is compiled, so the difference between the two really isn't that big a deal.

The main gain from code would be some optimisation that the engine doesn't offer.

Which means that since each game is different, trying to come up with a meaningful difference between the two is pointless, unless it's for the corner cases.

Or you really like to code.

I'd point out that parts of the runtime, like the collision engine and pathfinding, are extremely well optimised. If you write your own JavaScript code equivalent and don't spend several weeks optimizing it to the max, then Construct will probably still be faster, even with events.

agree with newt the performance benefit you get from scripting vs events is negligible, the real benefit from scripting comes from complex data structures imo. you have alot more freedom to freely manipulate data and store data. that said with that extra freedom you can fine tune some algorithms that you have on the event sheet and you might get a bit more performance. but it really depends on what you are doing, for general game play logic you wont see that big of a boost. just take a look at the ghost shooter example it implemented using full scripting and full events and the performance is very similar, mind you its a very simple implementation. one thing i noticed from comparing both scripting had a few frame drops to like 57 fps every once in a while and the event based one stay at a constant 60 fps. mind you i was just looking at the debugger and did not dig too deep into the metrics. you should explore it on your own for the use case of you game. i'd say the way to go is a mix, pure scripting does not seem like a full replacement for the evening system, they should be used in conjunction to get the most out of construct, but like i said just my opinion.