Recently, there have been a noticeable performance downgrade when performing debugging actions.
For example, press and hold F8 (Step over) you'll notice a consistent latency after 4-6 instructions,
i.e. 4-6 instructions are stepped over, then a delay will occur
Another example in which this latency is noticeable, select the instruction below the one you're currently at, then press F4 (Run until selection) and notice the small delay despite the fact that both instructions are just below each other
I don't know when has this started to happen, but you can compare the performance of the latest snapshot vs. this one snapshot_2016-10-31_23-29 and you'll definitely notice the difference.
The Latest snapshot whose performance is natural/fast: snapshot_2016-11-18_18-21
The first snapshot whose performance is affected/slow: snapshot_2016-11-20_22-01
Hm the commits you mention don't seem to correlate with any changes related to GUI performance. I will check it some more though. What kind of numbers do you get for events/s? Mine is between 24 and 30 consistently.
I didn't actually mean that those specifically are the faulty commits, just stating what's inside commithash.txt in case that helps to determine which commits (between both) could be the cause.
Anyway it's the same reason as #516 😞 , the difference here is that kaspersky doesn't have to be disabled during OS startup to solve the issue.
When it's turned off: events/s = 20-30 (both snapshots).
When it's turned on: events/s = 19-28 on snapshot_2016-11-18_18-21,
and 9-12 on snapshot_2016-11-20_22-01 (and the new ones).
I never noticed this before because i was using builds from October most of the time, which (as every other builds before them) don't have this problem, it only became obvious when i started using the latest snapshots consistently a couple of days ago.
Very sorry about this misleading/useless issue.
@wk-952 yeah the commit has is definitely very useful! I checked the commits in between briefly but I will check again. As for Kaspersky, I have no idea what I can do about it. If I find the time I will profile but it's rather mystical. Could you also try with GleeBug? Perhaps the speed improvement in that engine would make this stuttering less noticeable.
I will try to find what could have caused the issue since there appears to be something in the code that triggers the issue, so I reopen the issue. If you find any other information that's very helpful. Thanks!
Sorry, I have to say this:
This issue is 1337.
With GleeBug (stepping-over x32dbg.exe):
events/s = 22-30 on both snapshots (and latest ones).
events/s = 19-25 on both snapshots
Definitely better than 9 events/s.
Well I guess GleeBug will be the next goal then 😄