We need to talk about the Jank!

Here is my Performance Profile, you can clearly see that GC is being triggered right after some Construct related runtime work.

Here is a quick example I came up with for the time being. (Download Example: Link)

How to reproduce:

1. Open In C3
2. Run preview or export+upload as HTML5 (optionally enable fullscreen using F11 key)
3. Enable "Spawn Auto" mode
4. Notice occasional jank caused by GC

Let me rephrase.

Make a test where objects aren't destroyed.

Not a common method for Construct, but often called object pooling.

Did it, removed everything except the rotating sprite (needed for canvas refresh) and it did jank again.

I'd say we should wait 1-3 days for any hotfix patches.

Personally not really seeing a point in creating a report with a HTML5 example that's using a single rotating sprite.

Here is a quick example I came up with for the time being. (Download Example: Link)

How to reproduce:

1. Open In C3
2. Run preview or export+upload as HTML5 (optionally enable fullscreen using F11 key)
3. Enable "Spawn Auto" mode
4. Notice occasional jank caused by GC

(Edit: No clue why half my post was missing but ok.)

This is interesting. I tried your example and... it´s not janking. The autorunner on the other hand is janking almost like a clockwork. This got me thinking... where is the difference? First I nuked the entire event sheet of the autorunner, the jank was gone. After un-nuking it and more carefully killing off event after event I was left with a single event, with a single action.

(Duh, why can´t I add more than one image to a post :V)

Anyway, after replacing the regular text object with a spritefont, the jank is entirely gone (apart from two janks right at the beginning) Could that be it?

This is interesting. I tried your example and... it´s not janking. The autorunner on the other hand is janking almost like a clockwork. This got me thinking... where is the difference? First I nuked the entire event sheet of the autorunner, the jank was gone. After un-nuking it and more carefully killing off event after event I was left with a single event, with a single action.

(Duh, why can´t I add more than one image to a post :V)

Anyway, after replacing the regular text object with a spritefont, the jank is entirely gone (apart from two janks right at the beginning) Could that be it?

I removed any text objects found inside the example and could still reproduce, this ain't it unfortunatly.

Hmm, weird. This totally fixed it for me. Here is the comparison, it still does indeed jank twice for some reason (it still says GC actually) but then it runs buttery smooth.

That's the issue we're all complaining about, GC shouldn't do any work at all (cause jank), especially not on systems like mine with more than enough memory available.

Again best thing would be to wait for hotfix patches over the next days in my opinion.

I think everyone's jumped to conclusions on this. The profiles actually show that GC is not the cause. The profiles show a long frame, and only a tiny amount of time taken up by GC. For example the profile posted by TheRealDannyyy shows a frame taking 68ms, but GC only taking 8ms of that. Why didn't it schedule another frame in the remaining 60 ms? It looks like it could have done, because it wasn't busy doing GC, but it didn't. Right now we don't know why, but it is too early to blame GC, especially since it looks like GC finished quickly with plenty of time to spare.

At 60 FPS there is 16ms per frame. A demo like 'endless runner' does a tiny amount of work per frame - let's be pessimistic and say it takes 4ms of time per frame. This leaves another 12ms idle while it waits for v-sync. The browser knows it has 12ms idle, so it does increments of GC work in that time, since it essentially hides the work in otherwise idle time so it doesn't affect performance. So an 8ms period of GC could be the GC working exactly as intended, doing increments of work in the idle time between frames. I don't think there's reason to be suspicious of any GC times under, say, 14ms.

We don't know what's causing the jank yet, but it won't help anything to prematurely accusing GC without sufficient evidence. It could indeed end up being GC, but the evidence doesn't suggest anything out of the ordinary yet. This also means it's also definitely too early to insist on changes to the engine - especially since I've seen browser engineers specifically advising not to try to keep objects statically allocated, since it can actually prevent JavaScript engines better optimising code.

Identifying the cause of issues is surprisingly complicated, which is alluded to in this blog post.

As ever the best approach is to find a way to reliably reproduce the issue (to the best extent possible anyway), and the fact I can't reproduce it suggests it's a device or system specific issue, so we should probably start collecting system specs and look for patterns in specs where the issue can be reproduced.