https://bugs.winehq.org/show_bug.cgi?id=49113
Bug ID: 49113 Summary: Wine heap performs badly when multiple threads are concurrently allocating or freeing memory Product: Wine Version: 5.7 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs@winehq.org Reporter: rbernon@codeweavers.com Distribution: ---
This can be easily reproduced with any synthetic heap benchmark, such as https://github.com/mjansson/rpmalloc-benchmark or https://github.com/daanx/mimalloc-bench.
Performance gets really bad as the number of concurrent thread increases.
For instance, running the rpmalloc benchmark with "<num threads> 0 0 2 20000 50000 5000 16 1000" parameter set, and 2 concurrent threads gives the following results (wine staging is testing with the staging heap improvement patches from https://bugs.winehq.org/show_bug.cgi?id=43224):
* win10 crt: 11977625 memory ops/CPU second, 106% overhead * linux crt: 5675754 memory ops/CPU second, 53% overhead * wine rpmalloc: 19700003 memory ops/CPU second, 131% overhead * wine upstream: 248333 memory ops/CPU second, 62% overhead * wine staging: 914004 memory ops/CPU second, 61% overhead
Increasing the number of thread makes the difference even worse for Wine.
In general this does not translate in much slowdowns, as memory allocation is rarely done in such highly concurrent way, but in some situations the difference is clearly noticeable, and in particular with many games during their loading times.