[Bug 49113] Wine heap performs badly when multiple threads are concurrently allocating or freeing memory

WineHQ Bugzilla wine-bugs at winehq.org
Thu May 7 00:21:34 CDT 2020


https://bugs.winehq.org/show_bug.cgi?id=49113

--- Comment #3 from Dmitry Timoshkov <dmitry at baikal.ru> ---
This seems to be going in the wrong direction (is the actual problem due to
locking primitives being inefficient?) since the whole effort has been driven
by an artificial tests, and as the result there's no visible improvement for
the real world applications. On the contrary Sebastian's patchset in the
staging tree was based on the research and proper heap manager design, and as
a result provided huge performance improvements for real world applications.

Just for the reference I'll copy/paste Sebastian's comment from the internal
wine-staging patch tracker that accompanies his patchset:

==============================================================================
https://dev.wine-staging.com/patches/submission/145/

New comments by Sebastian Lackner (slackner):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Sorry for the delay, but such a complicated patchset took a bit more time to
evaluate. During the last few weeks, Michael Müller wrote tools to evaluate
heap allocation performance. These tools allow to record the heap allocation
pattern for various applications, and to replay them with different heap
implementations. The result (tested with various applications and games)
confirms what I already suspected:

Although these patches by Niels Kuhnhenn help for some applications with a "bad
allocation pattern" (see bug 43224 for example), they [b]reduce[/b] performance
up to [b]30%[/b] in the "good case". This means that they are not really
suitable for Wine Staging, users certainly would be upset about such a severe
performance regression.

This result is also not really surprising - the whole idea is based on
heuristics and "try & error", instead of a proper heap allocator design. I can
understand that users are willing use it this workaround for certain apps, but
it is not the correct solution. Since noone else seems to be working in this
area at the moment, I've decided to give it a shot myself. The result is
available at https://dev.wine-staging.com/patches/156/, please give it a try.

The new heap allocator uses (inspired by the way how it works on Windows)
various fixed-size free lists, and a tree data structure for large elements.
With this implementation, I get up to [b]60%[/b] improvement for apps with the
"bad allocation pattern", and up to [b]15%[/b] improvement in the "good case".
I am not aware of any application where this reduces performance, but of course
this needs more careful testing. Michael was also planning to provide some more
precise evaluation in the release notes or as a separate blog post after it has
been merged.

Nevertheless, the newly proposed patchset is certainly better than this
attempt, so I'm going to mark all patches as superseded (except the prefetch
and wined3d patch, which still have to be evaluated separately).
==============================================================================

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.


More information about the wine-bugs mailing list