Hosting in a worker (r137) - how to compare performance?

Measuring the performance difference is difficult, the most obvious way is the CPU Profiler in debug mode. But that doesn't really tell the whole story. For instance, the CPU profiler isn't good at showing spikes ( which cause missed frames and jank ), as it shows live performance if you have heavy usage for a frame or 2 you are unlikely to see an accurate representation of that.

While working on the procedural terrain demo I spent quite a while looking at performance to make sure that it ran smoothly. Due to the way the game works it generally has quite a low CPU level, but has VERY high spikes when you cross a loading threshold ( which is quite often ). These spikes would often cause dropped frames, which is unpleasant while moving around. To test what was causing them I mostly used performance recordings from chrome dev tools, as you can see frame times and CPU usage flame graphs for the duration of the recording. I tried testing worker mode to see if it made a difference. However, due to the way OffscreenCanvas works Chromes framerate is technically 0 when your using worker mode... So it's difficult to even tell if your dropping frames! You can however check how much frametime you used, which is fairly close.

Performance with worker mode is... different, before xmas I was seeing a notable performance improvement with the procedural generation demo, but now I'm seeing a fairly large drop. This may partly be due to changes I made since then ( reducing loop iterations mostly ) but it may also be changes by the Chrome team. It's hard to tell. It's biggest win is that if your game is using significant CPU time it won't slow down whatever work the main thread is doing ( DOM elements, mouse movement, scrolling, audio ) and vice versa.

I'd have thought there would be little CPU performance difference (it's the same JavaScript code after all), and either none or a small improvement on GPU performance (since it can issue frames off the main thread). So I wouldn't expect any huge changes - the main benefit is it runs off the main thread so browser work on the main thread won't jank the game.

Still it's worth verifying this with performance measurements - and for those, just use the same ones as ever, there's nothing special about performance measurement in worker mode. E.g. measure the FPS, CPU utilisation, GPU utilisation, etc.

Worker mode biggest benefit is not that you can export with it or not, but possiblity that some bad loop etc does not crash your editor, resulting you loosing a lot of work. Now it stable enough to keep it constantly on.

Gameplay seems a bit smoother with worker exports, but its Dt is not constant and also varies depending on browser so very smooth lerps/tweens etc could show some jankiness, also it's same with other browsers even when there is no worker mode.

Not related but.

What Nepeo said "VERY high spikes when you cross a loading threshold"

This is pretty awful, sometime it feels like there is small spike(1-2 tick) but it somehow overflows into ~0.2sec. Not sure what causes it.

I just tested it on my project which has quite a large number of collision checks and draw calls. It usually gives me a 90-100 FPS range and occasional drops to 80+ without web worker, but gives me constant 100 FPS no drops at all with :)

Hmm... maybe GC heuristics work differently in a worker?

Ashley

Hmm... maybe GC heuristics work differently in a worker?

I expect the scheduler to behave differently at least, so yeah GC timing is probably different as well. I'm not sure what the threading behaviour of Orinoco is when your in a worker, so that could effect how long GC takes compared to main thread as well. JS execution time definitely seems to be different.

It's hard to keep track of heap size and frame rate in dev tools when using worker mode because it tracks the main thread.

Maybe we should file dev tools bugs on crbug.com to get tools to track that.

Is the web worker functionality supposed to work in nw.js?

Ashley