libde265: Use process-local sync primitives on Windows. #480
Conversation
This issue came up when running libheif+libde265 using Wine, manifesting as severe performance degradation. Windows-specific code is using Win32 mutex for cross thread synchronization, both directly and to implement conditional variables. This is problematic on Wine because it causes global state change exchange on every mutex access. On Wine NT objects state is managed in a separate resident process, each user process communicates with it to update object state. High frequency access is going to cause performance problems as a result. Performance will degarde further if multiple process are running at the same time, each using same large amount of such calls. Proposed change is using API that is available since Windows Vista. Signed-off-by: Nikolay Sivov <[email protected]>
Signed-off-by: Nikolay Sivov <[email protected]>
|
Thank you for this. That's really helpful since I am not a regular Windows (or Wine) user. I am wondering: libde265 was written before C++11 was widely available, but now, we could simply use These references seem to suggest that using the C++11 types might be even better: |
|
Yes, I think this will work just fine. I see libde265 is already using std::mutex for library init/deinit functions, so it won't be a new addition. The build I tried was using VS 2022, using std::mutex and std::condition_variable will link to msvcp140.dll for sync functions, and already does for existing std::mutex. Regarding CRITICAL_SECTION on Win8 point, I checked what we have implemented in Wine for CRT, and we do indeed use CONDITIONAL_VARIABLE + SRW for those functions, for newer runtime versions. So that checks out. So yes, I'd be happy to test the changes. |
|
Just checking, @farindk. Are you working on redoing this with mentioned C++ sync functionality, or should I maybe give it a try myself? |
…ith c++ std-library classes (#480)
|
I've now replaced all mutexes, condition-variables, and threads with std-c++ classes. Does that work for you with Win32? |
This issue came up when running libheif+libde265 using Wine,
manifesting as severe performance degradation.
Windows-specific code is using Win32 mutex for cross thread
synchronization, both directly and to implement conditional variables.
This is problematic on Wine because it causes global state change
exchange on every mutex access. On Wine NT objects state is
managed in a separate resident process, each user process communicates with it
to update object state. High frequency access is going to cause
performance problems as a result. Performance will degarde further
if multiple process are running at the same time, each using same
large amount of such calls.
Proposed change is using API that is available since Windows Vista.