Emulator

Check out what I said in this other similar bug report:
https://bugs.dolphin-emu.org/issues/12553
The code in the specific commit you mentioned doesn't really run when games are running, unless you have a faulty USB cable that constantly disconnects and reconnects devices (or a similar problem).
In that case, please check and paste here your ControllerInterface log.
And even when the code in the commit runs, it should only affect performance if you have an input configuration window open.

I am just using keyboard and mouse, no controller is attached. Deleting shader cache didn't help.

I tried my own appveyor build reverting every commit in PR#9702 one by one. Reverting this one line fixes the performance for me https://github.com/dolphin-emu/dolphin/commit/83ea16f40238fa82981221ba65061a7094b2a64b#diff-6b1d0b09968daf1d99fe6301f5ef540216e408709ee1a1fd10b2c451d25c9bbaL331 I am not sure why, it was just trial and error.

I would kindly ask you to try testing the commits again before I investigate, because it does sound quite unlikely. And yes, check your log.

Fresh Dolphin configuration (deleted "user" folder). Using the same settings in all three runs. Deleted "user/cache" before each run.

Official build 5.0-14367 - CPU usage 17% & 22%

https://i.imgur.com/SER0PB6.png

Official build 5.0-14382 - CPU usage 70% & 89%

https://i.imgur.com/mbSin80.png

AppVeyor build 5.0-14445 - CPU usage 20% & 11%

https://i.imgur.com/5igfv6m.png

Only change is "MappingWindow.cpp" from previous commit https://github.com/dolphin-emu/dolphin/commit/626c686fee8a7d116e86096a283dc0346327524e

https://ci.appveyor.com/project/vladkosi/dolphin/builds/39675975

Ok I will take a look. Could you post the post i mentioned though?

Forgot to include the Official 5.0-14445 build

https://i.imgur.com/IRCwvMW.png

Can you try to disable DSU as well?

It is disabled. This is the default configuration, I only changed few graphics settings.

So AppVeyor build 5.0-14445 (dirty) is the latest version with this line https://github.com/dolphin-emu/dolphin/commit/83ea16f40238fa82981221ba65061a7094b2a64b#diff-6b1d0b09968daf1d99fe6301f5ef540216e408709ee1a1fd10b2c451d25c9bbaL331 reverted, which effectively makes the file identical to https://github.com/dolphin-emu/dolphin/commit/626c686fee8a7d116e86096a283dc0346327524e
Is that what you meant?
If so, I'm gonna ask you to put a breakpoint in "void MappingWindow::RefreshDevices()" because that supposedly only runs when the user presses the refresh devices button, which isn't even clickable unless that widget is open, and by checking the code again, it would be very weird for the "button clicked" event to be trigged by code without a user input.

Also, instead of checking the CPU utilization, try setting the emulation speed to unlimited and see if there are actually any emulation speed regressions please.
Thanks.

Yes, latest master, "MappingWindow.cpp" replaced with file from commit 626c686fee8a7d116e86096a283dc0346327524e.

Line #5 in the log https://ci.appveyor.com/project/vladkosi/dolphin/builds/39675975?fullLog=true

Sadly I can't install Visual Studio right now, hence the appveyor builds.

If you can provide me with test builds I am happy to try them to see what's going on.

Ok. See my last comment about unlocking the emulation speed.
Did you actually test everything twice or are the screenshots from the first time you tested everything?

The screenshots are from 4 hours ago, I've tested it plenty times. I have every build in separate portable folder with identical configurations.

Emulation speed is definitely lower.

5.0-14367 - FPS around 90, VPS around 190

https://i.imgur.com/aVaMFgJ.png

5.0-14382 - FPS around 60, VPS around 120

https://i.imgur.com/TwbVtvE.png

5.0-14445-dirty - same as 5.0-14367 FPS around 90, VPS around 190

https://i.imgur.com/WhWtxeh.png

I tested both build 14367 and 14382 and to me the unlimited emulation speed is exactly the same.
Plus, I experimented with the code you said that fixed the problem after reverting it, and it does not stall nor run on the emulation/CPU thread in any way, the emulation still runs at flawless ~350% if I spam click the "Refresh" devices button, so even if something was clicking that underneath (which is not because it would show in the logs), it would not affect emulation performance (which it would instead would have before my changes).
I'm gonna ask you to redownload both builds, re-delete your whole Dolphin documents folder (before each test) and try again. If you still find a speed regression with 14382, then try to revert commits individually again, because the change you mentioned can't be the reason of an emulation speed regression.
Thanks.

Could you try both:
5.0-14445-dirty
and
5.0-14445 (not dirty, with no changes)
from AppVeyor, and maybe upload them here, so we can prove if the change you mentioned actually impacts performance?
Please make a new build with the reversed change, as it could have been a build machine "bug".

To get those FPS/VPS values, are you running dualcore completely unsynced or something?

"clean default settings" so yes, dualcore is enabled. Only change from defaults is the unlimited emulation speed and emulated CPU clock override.

Based on your readings, the game is running 20/60 natively, which doesn't make sense since it's a 30/60 game.

I didn't mean is dual core enabled, I meant did you disable syncing entirely which is a hidden option. If you're default the answer is no but I still don't get how you have such a weird reading for this.

The setting used are in the attached ZIP file.

Unmodified appveyor build from master:

https://ci.appveyor.com/project/vladkosi/dolphin/builds/39682698?fullLog=true
You can download it from here: https://ci.appveyor.com/project/vladkosi/dolphin/builds/39682698/artifacts

With 200% clock override:
https://i.imgur.com/vMT1Qoc.png

Appveyor build from master with "MappingWindow.cpp" replaced from commit 626c686fee8a7d116e86096a283dc0346327524e

https://ci.appveyor.com/project/vladkosi/dolphin/builds/39683218?fullLog=true
Download: https://ci.appveyor.com/project/vladkosi/dolphin/builds/39683218/artifacts

Exactly the same settings with 200% clock override:
https://i.imgur.com/cQmZiNs.png

Second PC without clock override:

5.0-14447 - 40 to 45 FPS, 115 VPS
5.0-14447-dirty - 50 to 55 FPS, 145 VPS

When I was testing the appveyor builds few days ago, at first I reverted the whole commit https://github.com/dolphin-emu/dolphin/pull/9702/commits/83ea16f40238fa82981221ba65061a7094b2a64b and that fixed my performance.

Then I saw this part in the commit message: "Avoid calling ControllerInterface::RefreshDevices() from the CPU thread if the emulation is running and we manually refresh devices from Qt, as that is not necessary anymore."

So I tried reverting just the "MappingWindow.cpp" file (the only file with changes related to "RefreshDevices()") and that fixed it too. I don't know the reason why or how it works but clearly it does, on two separate machines.

Can you build another AppVeyor version with any random change, and test the speed then? Don't change MappingWindow.cpp, just change any other file which should be irrelevant to the emulation speed, and then report the numbers again.
I've compared the two binaries you uploaded and they are extensively different, despite the only change supposedly being one line, so that is weird.
Also I've tested their performance and it's exactly the same on my machine.

You can't compare release binaries by contents like that. They are heavily optimized by the compiler. Just one line in source code can produce massively different binary.

Have you tested on 200% or even 400% clock override where the performance difference is really large?

From another chat:

So something interesting came up
changing the line the user has mentioned
between the old: Core::RunAsCPUThread([&] { g_controller_interface.RefreshDevices(); });
and the new: g_controller_interface.RefreshDevices();
does COMPLETELY change the binary
so the compiler puts the binary together in a very different way.
if any other line is changed, the binaries end up having very little differences
so maybe it's the dependency from "Core" in that object that gives that user that speed up?
Removing Core::RunAsCPUThread(...) does take away any dependency from "Core", in MappingWindow.cpp
Still, the Qt project has other Core::RunAsCPUThread(...) around, they are just in other files.
In any case, performance is always exactly the same on my machine.
And as expected "MappingWindow::RefreshDevices()" does not run, unless the user clicked its connected UI button.
So if this was real, it wouldn't be a problem with my changes itself, but with the compiler, I assume. I really wouldn't know how to proceed for here.

We just need to find out why you can't reproduce the performance regression between official builds 5.0-14367 and 5.0-14382.
Because I definitely can, using the default settings and on two different machines.

I'm on AMD 5900X, so maybe it's an "Intel" problem, though I couldn't see way.
Did you put both builds in equivalent folders (like on the same hard drive) and run them at different times?
All I can do is ask others to test for performance regressions as well, but I believe a few already tried and also didn't have any.

Could be an Intel thing. I can test it on third machine, my laptop, but that is also an Intel.

Yes, everything is in separate folders, on same drive, with the exact same config files, run at different times.

These are the exact steps to reproduce on my two machines:

1. download https://dl.dolphin-emu.org/builds/b2/c9/dolphin-master-5.0-14367-x64.7z
2. download https://dl.dolphin-emu.org/builds/a3/c2/dolphin-master-5.0-14382-x64.7z
3. extract each build to separate directory
4. copy the "portable.txt" file and "user" folder from the attached ZIP https://bugs.dolphin-emu.org/attachments/8450/Dolphin.zip to each directory making it portable (these are default Dolphin settings, only change is "ISOPath0 = ." and unlimited emulation speed)
5. copy "Metal Gear Solid The Twin Snakes Disc 1.iso" (MD5 0720e3d3fe42587b2ce22fbb8a60b847) to each directory
6. set emulated CPU clock override to 200%
7. start new game, skip all cutscenes/codec conversations to the part on the screenshots and use the codec to start a new conversation

5.0-14367 stays at 97 FPS
5.0-14382 drops to 55-57 FPS and while Colonel is talking audio is stuttering. The FPS drops are present during the intro cutscenes at random times, but here I can reproduce it 100%.

Same with he latest master https://dl.dolphin-emu.org/builds/20/37/dolphin-master-5.0-14447-x64.7z FPS drops to 55

The performance regression only happens in dualcore, that's why I was unable to reproduce it. Single Core is actually faster in this game for me anyway.

That's correct, with dualcore disabled I get lower performance (98 to 70 FPS) on both builds, but the drops to 55 FPS on 5.0-14382 are not there.

Same with the latest master.

Pardon my intrusion, but I've been following this discussion ever since I got notified that an issue related to my issue was opened, and I decided to redo the testing I did with Pokemon Battle Revolution, and it seems that there indeed is a regression in performance with dualcore.
I probably had dualcore enabled as an override during the initial testing, while disabling it later when I went and cleared the shader cache and running the second testing the next day.