The cost of ArrayBuffer creation

[kvark]

In the discussions around data transfers (e.g. #491), vertex buffers, and other parts, we repeatedly hit a case where the cost of creating many ArrayBuffer objects should be considered. I wanted to see if we have concrete evidence to inform the costs here, so I made a small benchmark - https://jsperf.com/mass-arraybuffer-creation/1

Basically, all the browsers can comfortably create more than a million ArrayBuffer objects per second, even when:

1. they are wrapped into new Int32View wrappers, which isn't necessarily the case for WebGPU usage.
2. no explicit detaching is invoked, while WebGPU would know at concrete time when to unlink the storage (e.g. GPUUploadPass.finish()).
3. data is allocated on the heap, while WebGPU will in most cases provide access to external data that already exists (and if not, the costs of managing this data are not something we are trying to save here, we are only talking about ArrayBuffer objects themselves).
4. Gecko JS engine isn't doing the best job at GC-managing ArrayBuffer objects specifically (can't tell about others), we have a room for optimization here.
5. benchmarking overhead is not considered, which could take place since our iteration is so small

That gives more than 10K objects per frame, and possibly higher. In different words, if 100 ArrayBuffer objects are constructed per frame, when running at 100+ fps, we'd be losing less than 1% of the content process CPU time.

I'm not trying to drive any conclusions from this, just attempting to align our expectations in the context of the future discussions. If you think the benchmark is bad (and I feel bad), please help making it better :)

[magcius]

I've found that, at least with things like Float32Array, the cost of creative them is expensive, and much more expensive than normal array creation. This has been noticed by others as well, e.g. toji/gl-matrix#359.

I have not been able to reproduce this consistently in a microbenchmark scenario, which implies that the compiler might be smarter than I think. From personal experience, I have noticed that creating a modest amount of Float32Arrays per frame (I think the number was around 1,000?) was about a 15fps reduction. This might have been an intermittent browser bug. I will try to see if I reproduce it tonight.

I don't know if it's an artifact of creating the backing store/the ArrayBuffer, or the Float32Array wrapper type. Perhaps there is a way of creating ArrayBuffer objects from the host that is fast.

This is a separate issue, from my understanding, from GC behavior. Stuttering and Major GC pauses are hard to predict and hard to schedule. My observation on GC behavior has changed drastically in the 6+ years that I've been working on web graphics, and I would have to look at it again. Last I tried, GC pauses from AudioBufferSourceNode got a lot worse compared to when I last looked.

These observations are from Chrome. Unfortunately, Firefox's WebGL layer has been too slow for me to measure consistently there.

[kdashg]

(Can you link me to the bug for your WebGL slowdown in Firefox? That's generally unexpected, and I'd love to triage it!)

[magcius]

In the process of investigating to file a bug, I found an area where I was accidentally allocating a new list roughly per draw call, and I'm doing somewhat ~1500 draw calls. Eliminating it seemed to provide a decent performance increase.

magcius/noclip.website@b170abb

I should have a bug report for you sometime soon.