[PATCH 0/1] MR6655: wine/debug: Don't call wine_dbg_log() if a debug channel is disabled.
This prevents debug functions from being executed in disabled TRACE() statements (for example debug_d3dtstype()) which reduces unnecessary logging. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6655
From: Aida Jonikienė <aidas957(a)gmail.com> This prevents debug functions from being executed in disabled TRACE() statements (for example debug_d3dtstype()) which reduces unnecessary logging. --- include/wine/debug.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/wine/debug.h b/include/wine/debug.h index ce5e141ccb7..1ebc0f5012e 100644 --- a/include/wine/debug.h +++ b/include/wine/debug.h @@ -82,7 +82,7 @@ struct __wine_debug_channel (__WINE_GET_DEBUGGING##dbcl(dbch) && (__wine_dbg_get_channel_flags(dbch) & (1 << __WINE_DBCL##dbcl))) #define __WINE_DPRINTF(dbcl,dbch) \ - do { if(__WINE_GET_DEBUGGING(dbcl,(dbch))) { \ + do { if(__WINE_IS_DEBUG_ON(dbcl,(dbch))) { \ struct __wine_debug_channel * const __dbch = (dbch); \ const enum __wine_debug_class __dbcl = __WINE_DBCL##dbcl; \ __WINE_DBG_LOG -- GitLab https://gitlab.winehq.org/wine/wine/-/merge_requests/6655
This will slow down every enabled trace, I don't think that's a good trade-off. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6655#note_84750
On Fri Oct 11 14:15:39 2024 +0000, Alexandre Julliard wrote:
This will slow down every enabled trace, I don't think that's a good trade-off. So should I add some caching to `__wine_dbg_get_channel_flags()` to minimize that potential performance reduction?
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6655#note_84751
Using a benchmark [1] to test for example, this helps a lot with performance when WINEDEBUG="err-d3d". I also get a similar score up to a certain point at least, with this patch and without it, when not setting 'err-d3d', though I don't know if that is a good test on the enabled slowdown. 1. http://www.playonline.com/ff11eu/download/media/benchmark03.html?pageID=medi... -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6655#note_84752
On Fri Oct 11 14:47:40 2024 +0000, Jimi Huotari wrote:
Using a benchmark [1] to test for example, this helps a lot with performance when WINEDEBUG="err-d3d". I also get a similar score up to a certain point at least, with this patch and without it, when not setting 'err-d3d', though I don't know if that is a good test on the enabled slowdown. 1. http://www.playonline.com/ff11eu/download/media/benchmark03.html?pageID=medi... If you want to run benchmarks you should use `WINEDEBUG=-all`, anything else is pretty much meaningless.
In particular, doing WINEDEBUG=err-d3d will give even worst results, because it allows d3d log level to be changed dynamically through the taskmgr, which means every trace will have to check if the level has changed. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6655#note_84753
On Fri Oct 11 14:47:40 2024 +0000, Rémi Bernon wrote:
If you want to run benchmarks you should use `WINEDEBUG=-all`, anything else is pretty much meaningless. In particular, doing WINEDEBUG=err-d3d will give even worst results, because it allows d3d log level to be changed dynamically through the taskmgr, which means every trace will have to check if the level has changed. The benchmark was only used as an example and easier to test than the full game (Final Fantasy XI Online), which has the same issue with about 10,000 lines of output coming in from err d3d now, as also described in bug 57207 [1], and it was a bit surprising that 'err-d3d' would actually make things worse.
I does seem like it was to be expected, but I have not bumped into that effect before, when actually disabling things instead of the reverse. 1. https://bugs.winehq.org/show_bug.cgi?id=57207 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6655#note_84754
On Fri Oct 11 15:08:07 2024 +0000, Jimi Huotari wrote:
The benchmark was only used as an example and easier to test than the full game (Final Fantasy XI Online), which has the same issue with about 10,000 lines of output per second coming in from err d3d now, as also described in bug 57207 [1], and it was a bit surprising that 'err-d3d' would actually make things worse. I does seem like it was to be expected, but I have not bumped into that effect before, when actually disabling things instead of the reverse. 1. https://bugs.winehq.org/show_bug.cgi?id=57207 On that note, it does seem like using '-all' indeed alleviates the issue as well, and I can still enable things like 'fps' with it which I usually have going with this one, so that is an option in short term at least.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6655#note_84759
On Fri Oct 11 15:18:53 2024 +0000, Jimi Huotari wrote:
On that note, it does seem like using '-all' indeed alleviates the issue as well, and I can still enable things like 'fps' with it which I usually have going with this one, so that is an option in short term at least. It also sort of depends on *who* is benchmarking it; perf optimizations are usually tradeoffs, and one particular benchmark might report perf increase while it slows down basically every practical application. Just the fact that "it allows d3d log level to be changed dynamically" is an assumed knowledge that can only be discovered by digging the docs and/or source code.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6655#note_84817
On Sat Oct 12 07:13:44 2024 +0000, Jinoh Kang wrote:
It also sort of depends on *who* is benchmarking it; perf optimizations are usually tradeoffs, and one particular benchmark might report perf increase while it slows down basically every practical application. Just the fact that "it allows d3d log level to be changed dynamically" is an assumed knowledge that can only be discovered by digging the docs and/or source code. While benchmarks shouldn't be run with logging on, I'd really like to see a solution for the problem that e.g. WINEDEBUG=-d3d or WINEDEBUG=warn+d3d slows down execution tremendously. This can hamper development by unnecessarily slowing down the program by an order of magnitude, and it can also greatly confuse someone who (quite reasonably, I think) doesn't anticipate this is the case. I have multiple times thought that I made a change which regressed performance, wasted hours trying to bisect, only to discover that I had at some point added "-d3d" to the flags.
Perhaps the best solution here is to have an explicit flag that allows the channel to be set dynamically, while the current WINEDEBUG syntax sets the level immutably and avoids the need to recheck. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6655#note_84945
This merge request was closed by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6655
Superseded by 9245a5e23b4b091465a35efe4fb1c769bcface25. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6655#note_89681
Superseded by 9245a5e23b4b091465a35efe4fb1c769bcface25.
Thank you! -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6655#note_89748
participants (6)
-
Aida Jonikienė -
Alexandre Julliard (＠julliard)
-
Elizabeth Figura (＠zfigura)
-
Jimi Huotari (＠Chiitoo)
-
Jinoh Kang (＠iamahuman)
-
Rémi Bernon