Performance is now extremely slow on modern browsers

[krisnye]

This library used to be fast, but modern browsers are now allocating simple objects so fast that they are effectively free. Array allocation is still much slower and ArrayBuffer allocation is extremely slow.

A new math library is needed to take advantage of this. It should use simple classes, all functions can return new instances instead of using awkward out parameters and there should only be conversion to ArrayBuffers as a final function when assigning to webgl. (technically those arraybuffers can be reused as webgl doesn't retain references to them after you assign)

Check the performance of different approaches here:

https://jsperf.com/webgl-math-library-comparisson/20

[stefnotch]

#358 (comment)

I'll take a closer look at the JSPerf later

[stefnotch]

I added a new test case where I'm caching glMatrix's Float32Arrays, which greatly increases the performance, however vanilla JS objects are still faster: https://jsperf.com/webgl-math-library-comparisson/21

However, when using those rather limited test cases, glMatrix seems to outperform vanilla JS objects: https://jsperf.com/glmatrix-getclosesttonline/ Feel free to expand them with more libraries. I'd love it, if you could prove me wrong.

A WebAssembly port of glMatrix is planned, however WebAssembly still has a few limitations.

[krisnye]

This is weird. You have any ideas on why the results in the first comparison are so different from the second?

[krisnye]

@stefnotch OK, I witnessed the previous performance of your sample with literal objects being slower. I updated the sample to use a small Vector class and the performance is back to what I witnessed in the other samples. Maybe Chrome/Firefox are more aggressively optimizing when they can see functions being called with instances sharing a consistent prototype. (I'm guessing that those object literal samples end up using a slow lookup dictionary internally in Chrome and the newer class instances are turned into efficient hidden classes and the function is optimized with them in mind)

Vector classes are doing 235 K-ops/sec vs 78 optimized in gl-matrix. That's even when noting that the objects are pure functional and are doing 2 new allocations within that function (in the .subtract implementation).

On Firefox the difference is even more significant. 1.2 million ops per second (which makes me think that it may be optimizing the whole function away. That's why I added some side effect to other samples.)

https://jsperf.com/glmatrix-getclosesttonline/12

Please check it out and see if you can replicate my findings.

[krisnye]

I added back your older object test so we can compare the difference between using literal objects and using class instances and added Array as well which is also very fast.

https://jsperf.com/glmatrix-getclosesttonline/15

[stefnotch]

Thank you very much for taking your time to write those tests. I can replicate your findings. Apparently objects are now significantly faster than Float32Arrays.

I guess as it stands, glMatrix will have to improve, either by using objects or by using WebAssembly. Since I currently don't have time to rewrite this library with objects and other libraries that use objects already exist, I suppose I'll wait for WebAssembly to become better.

[krisnye]

@stefnotch I actually wrote a C implementation AND a WebAssembly implementation of the add/cross/dot sample both with and without linear memory access (to make it more realistic) and my findings indicate that going to WebAssembly will NOT gain you any significant performance benefits (except in Safari which is an outlier with excellent Wasm, but bad everything else).

Here is the document. I can send you my source code for the C and the Web Assembly and any of the other node versions if you like.

https://docs.google.com/spreadsheets/d/1SQPU4OwV5QeA8_peuTk49PDvT_djVVrq1TGd-OvWtzA/edit?usp=sharing

[krisnye]

A quick improvement you could do or recommend to others is just to set the array type to use normal arrays and not Float32Arrays, only converting to Float32Arrays before assigning to a WebGL API that expects them. Other than that, not much can be done without being an entirely new API. If you do write one I recommend treating all objects as immutable (while not actually calling Object.freeze because that's super slow).

Or not convert to Float32Array at all since setUniform seems fine with normal arrays.

[karhu]

I recently did a similar evaluation, but rather approaching this from the memory consumption side instead of the performance perspective. My findings also point in the direction of using normal arrays instead of Float32Arrays as backing store.

In short, new Float32Array(3) has a lot of overhead, I measured 200 bytes in Chrome, as opposed to an unrealistic but optimal 12 bytes or 20 bytes if you account for a pointer to the data. This number is confirmed by a V8 developer here: https://stackoverflow.com/questions/45803829/memory-overhead-of-typed-arrays-vs-strings#45808835

In contrast I measured ~96 bytes for a normal array.

[karhu]

Small update to the above, a class with x, y & z fields uses ~56 bytes, which also matches with other sources:

• 24 bytes object overhead, see https://www.mattzeunert.com/2017/03/29/v8-object-size.html
• 8 bytes for a pointer to the object from somewhere
• 3 properties, 8 bytes each

[krisnye]

@karhu There is a lot of overhead for allocating a typed array. You would not want to create them for small objects as happens currently in gl-matrix. You STILL would want to use them though when you are allocating a very large array of data as it keeps it much more tightly packed than when using javascript objects.

So, use idiomatic javascript classes for your vectors and matrixes but then store the results in a large typed buffer (which you are probably going to use as a webgl vertexbuffer)

[karhu]

@krisnye Yes of course, that's how we mainly use them in our code base. Unfortunately they tend to lead to less idiomatic and maintainable code, so I started to investigate alternatives ;) Was just a bit surprised that the typed arrays had that much overhead and figured it might be useful information in the discussion here.

[tobx]

Do you have any information about garbage collection? Creating many objects led to animation hickups when the garbage collector stepped in in older browser versions. Of course we could also reuse objects, but I would still like to know if the garbage collection of objects is as free as the allocation of those in modern browsers.

[krisnye]

I didn't do any testing of garbage collection in older browsers. As the title says, "performance is now extremely slow on modern browsers". I think most of us writing high performance graphics or games are primarily concerned about modern browsers.