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

  • In C3 r137 the option to Host in a web worker is available in project settings. Im wondering how to measure if this setting affects the performance of my game? I can look at gameplay and try to decide if it runs smoother, has less jankiness etc, but that's a bit subjective. How would I more accurately measure whether hosting in a worker improves performance? Or is it just a given that enabling 'host in a worker' will give smoother gameplay?

    How should it impact cpu usage for example?

  • 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 :)

  • Thanks for the info Nepeo Ashley

    Im not seeing any obvious difference with cpu or gpu usage. I might see less janks, as in 0 janks where before I would get a very occasional one, its hard to tell though.

    Is hosting in a web-worker likely to improve performance on mobile?

  • SnipG

    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.

    Yeah as I said it's just kind of how that game works, I based the logic on a similar project I've been working on in my spare time (Voxelcraft) which has a similar issue. Ideally the work would be broken up or done on a different thread so as to not hinder the framerate.

    On the procedural terrain demo when you cross a loading threshold it has to:

    - break the tilemap up into "chunks"

    - serialise each chunk, and store it in the dictionary

    - update the world position

    - for each chunk either generate world data or deserialise from the dictionary and place the data in the tiles

    So there is an awful lot of looping, serialisation, deserialisation, noise generation and tile updates. All of that has to somehow happen during a frame, and it normally does! Performance can be tweaked by changing the size of chunks and blocks, to reduce the number of loops and iterations ( loops cost more than iterations ). Also persistence can be ditched to remove the need to serialise the world. One idea I did toy with is to use multiple tilemaps and move them around, it's more complicated but would reduce the amount of work significantly.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • 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

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)