webrender scrolling example uses 17 (!) threads on Windows + huge memory regression

[fschutt]

This is a problem I've found very weird: The webrender scrolling example uses (for whatever reason) 17 (!) threads (and 213 handles) by default:

I mean I love multithreading and all, but isn't this a bit too much - I was under the impression that webrender itself isn't multithreaded at all and you have to implement asynchronous rendering yourself. But even then, it shouldn't take 17 threads, at most 2 or 3 threads.

The other part is a huge memory regression, which I noticed to happen somewhere between
2cb682553816200bb74ce75d3851753bc122f488 and cf9b780325f67c32637deac1256375492e81b4d2 - before, the memory usage was at roughly 30MB, then it jumped to 80MB for the default scrolling example - maybe there is something heavily wrong / duplicated in the rendering process?

While it doesn't impact rendering performance that much, it keeps me wondering what webrender needs 17 threads and 80MB RAM for.

[LifeIsStrange]

From my understunding, shouldn't the number of threads scale with the number of physical cores ? So if you have a 8 core cpu 8 threads spawn, if you have a 32 core amd threadripper it should optimally use 32 threads !
Using more threads than the number of cores seems to my poor understunding a performance loss (non shared memory and locks) ans a battery loss.
I make the assumption that Intel/AMD hyperthreading is automated and doesn't benefit From two real threads per core but one real and one artificial created by the OS/cpu microcode.
This assumption could be wrong.

HS but using llvm Polly can yield massively better performance for some multithreaded workloads.

[fschutt]

Yeah, it just dawned on me that this could be because of rayon, since I have an 8-core / 16-thread CPU. Since the default stack size in Rust is 2MB, 16 * 2MB = 32MB + 40MB base = 72MB - roughly the amount of memory used.

[fschutt]

Rayon itself doesn't seem to be the issue. Rayon was already included in webrender before 2cb682553816200bb74ce75d3851753bc122f488 and it runs with 30MB even with rayon. So I suspect that something happened after that what caused the huge memory bump.

[fschutt]

This is not a webrender bug, sorry for any confusion. The 79 MB shown in the process explorer was because the task manager doesn't update it's table frequently enough - the current scrolling example still takes about 30 MB. I investigated this and it seems to be connected to loading the default system fonts (i.e. "sans-serif") - these fonts being loaded all the time leads to a huge memory increase. But that is not the fault of webrender.