Analyze an application's performances

I am opening this issue because I am currently working on the implementation of a famous game as a web application, so I decided to use three.js coupled with socket.io.js for the front-end, and flask for the backend.
The result’s aesthetics is quite good, as I deployed it on Heroku here to see if we could play it online.


The only thing that bothers me is that it seems light at the beginning, but becomes quickly quite heavy, with the computer’s becoming noisy and the memory usage seemingly increasing a lot. I wondered if there were js threads running in the background, and tried inspecting thanks to Chrome and Firefox performance inspectors, but could not see anything relevant (increasing value somewhere).
It actually even tells me that a major part of the CPU is idle…
Capture d’écran 2020-11-22 à 17.14.31
So I have two questions :

  1. Do you know any tool which would be more precise to analyze and profile a three.js powered application, such as JMC for Java for instance, which is more intuitive than browser tools.
  2. Is it just possible that my front-end is too heavy, which seem weird as we are just moving objects and updating arrays (could come from the fact I use cannon.js, socket.io.js, OrbitControls.js, or that I do not use the .min.js versions ?)

Else, if you have a simple methodology to inspect your application’s performances, I am also interested.
The code is available here, if you want to give a look, the front-end is mainly stored in static/js/graphics/helperFns.js (graphics) and static/js/socket.js (web sockets).

Not impossible, but unlikely - .min versions are just smaller in size. As for cannon and socket - you can try disabling them in the code and see if it helps.

2 Likes

TBH, the build in performance analysis in Chrome is very good. If you are not seeing a hot spot or memory leak, you might have not looked at the right place.

3 Likes

Well, thank you for your answers, I followed both of them including stat.js, and trying to focus more on the different tools within the Chrome analyzer.
It seems that the required CPU is not really the problem here, but it is more about the GPU. I think that maybe some of my renderer’s options are too heavy to bear :

const renderer = new THREE.WebGLRenderer({antialias: true});
// Enable extension
renderer.getContext().getExtension('EXT_color_buffer_half_float');
renderer.setPixelRatio(window.devicePixelRatio);
renderer.setSize(window.innerWidth, window.innerHeight - padding);
renderer.shadowMap.enabled = true;
renderer.shadowMapSoft = true;
renderer.shadowMapDebug = true;

I remember that the last three options were for phongmaterial shadows on a texture with a, image mapped on it, and the first one was to remove some kind of warning in the console on Firefox. I will try to use renderer.info to get more feedback about the graphics.
Thanks for the help anyway, I will close this post as soon as I find the cause.

These two properties do no exists. If you want to enable soft shadows, do this:

renderer.shadowMap.type = THREE.PCFSoftShadowMap;

Thanks !
In the end, it just seems that three.js is quite heavy to run games at 60 fps, as it requires much GPU. I realized that when I tried to run a simple animation from three.js site for more than one minute. I just see two solutions :

  • Avoid calling animate() when nothing changes in my game

  • Maybe lower the frame rate as long as the animation remains smooth

Do you see any other optimizations that would be efficient to make an online game lighter to run ?

I’m afraid it’s incorrect to make statements like that. Whether an engine requires “much GPU” or not mainly depends on the used materials and thus underlying shaders. Meaning a PBR material (like MeshStandardMaterial) will require way more resources than a simple unlit material (MeshBasicMaterial). Besides, WebGL shaders are always translated to native shaders depending on the 3D API of your system (e.g. DirectX, OpenGL, Vulkan etc.). Hence, WebGL shaders require longer to compile (because of additional translation steps) but they are not executed “slower” on the GPU.

2 Likes

Krunker.io and quite a few other projects do prove against this statement (as @Mugen87 pointed out.)

It’s a matter of resource handling & optimizations (in js, in three, and in any other environment) - simply brute-forcing and hoping that GC & three take care of memory management will inevitably lead to 3fps. :’)

1 Like

The Babylon team has developed quite a useful tool for inspecting webgl

I’d be curious to see a snapshot of your frame, how many draw calls, how many binds, how many different shaders, sizes of buffers etc.

2 Likes

Well thanks @dubois, I will try spector.js asap, but @Mugen87 and @mjurczyk are right, it is new for me to use three.js to run a game, and I am not considering a lot embedded complexity for different materials, shaders, geometries, and so on.

So as my game is quite simple, I should replace a max number of features with simpler representations for my game to be lighter. spector.js might help me to see the impact of those changes, it should be instructive.

Thanks everyone for the answers btw