Debugging is slow.

Hi guys,

I'm using Rider(2023.1.2) for game development with Unreal Engine(5.1.1).

Both Step over(F10) and Step into(F11) take really long time to respond. How do I identify the cause of it?

3
16 comments

I'm experiencing the exact same issue.
Hopefully Jetbrains will fix the issue soon.

0

Hello Coquid93,

Are you experiencing this issue with the latest Rider version (2023.3.3)? If you are using the latest version of Rider, could you specify your OS and the UE version you are using?

1

I'm also experiencing this (in 2023.3.3). There's a noticeable delay (sometimes up to 10 seconds) before the watch window (or the variable state shown in the source code window) updates.

If I ever need to do any serious debugging, I *have* to switch back to Visual Studio - which is unfortunate.

0

Hello Neil Griffiths,

Would it be possible to send us debugger trace logs that would help us investigate this behavior?

  • Use Help → Diagnostic Tools → Choose Trace Scenarios action and pick Debugger trace scenario
  • Reproduce the problem
  • Use Help → Collect Logs to generate the log archive
  • Disable the Debugger trace scenario

You can use the Upload Service to send us the logs (logs are not publicly accessible) and leave a comment with Upload ID in this thread.

0

Kirill Filin

Here's the version of Rider I'm currently using
JetBrains Rider 2023.3.3
Build #RD-233.14015.60, built on January 19, 2024

And i am using the current source version of the Unreal Engine code, forked from the 5.3.2 Release version.

I have reproduced the issue and uploaded it. (2024_02_05_229bohBX8dtJfCnFWDPD5L)

When I actually turned on Diagnostics and tried to reproduce the problem situation, Step into is faster than I thought, but I couldn't check the variable value for a very long time with “Collecting...” message.
It felt like I wasn't actually stepping.

I would be grateful if you could check it out.

Oh, and there's another problem,

the user-friendly view of Unreal data types is not being applied.

I opened urpoject as a Rider, and noticed that the Engine Solution View shows UEDataFormatters_2ByteChars.py.
I've tried using the paths "UEDataFormatters" and "UEDataFormatters_2ByteChars" in the "script import" line of the ~/.lldbinit file, but the user-friendly view is not being applied.

I hope you can check this as well.

0

Is there any update on this topic? This issue recently started affecting multiple people on the team, disrupting their work.

0

Hello everyone,

We are still investigating the issue, however we've recently discovered that a couple of third-party antivirus/data protection solutions are affecting debugger on Windows and Mac systems. 

Here's the list of products that can cause debugging performance issues:

  • CrowdStrike Falcon
  • Hitman.Pro Alert

Please let us know if you are using one of these solutions in your environments.

0

No, I'm using neither of those. I'm able to easily reproduce this issue with *any* UE5 project on both my work PCs and my home PCs. All I have to do is add some variables in the Watch window, insert a breakpoint in, say, any actor's Tick() function and let it hit the breakpoint a couple of times. Both the Watch window and the variables take a significant amount of time to be able to see their current values.

Since I can reproduce it on multiple PCs (that are also a mixture of Windows 10 and 11), I doubt that it's related to AV software - I suspect it's far more likely related to Rider trying to fetch the current values of every variable visible in the source editor… but that's just a guess.

0

I am still facing the issue and unable to dubug or run my project!

0

This is the second ticket I've found for this, the first have been back in 2022! Is there really no update on this? Looks like my company and I will be switching back to VS2022…

0

I tracked this issue deeply and found a solution that worked for my situation.
I don't know if this will work for everyone, but I'm writing in the hopes that it will help.


My working environment.
Using the source version of Unreal Engine.
Working on a Mac.
Problem situation.
Variable Evaluation time is too long when debugging.
This is causing debugger hitching when I use Variable Evaluation during debugging.

Solution.
The solution is to add a line to ~/.lldbinit.

  • setting set symbols.load-on-demand ture

As it turns out, if you have a lot of modules in the lldb, when evaluating a (UE engine) expression, there is a process of parsing all the symbols that are not needed, which takes a very long time.
So, for this reason, you can set an option to parse only the modules you need to evaluate (starting in 2022).

 

0
Hello,

Thank you for sharing your experience and potential workaround. We will check if adding this setting gives noticeable debugging performance growth and consider on potential improvement.

Have a nice day!
1

Hello,

Is there no any solution? I have tried the solution of @Coquid932 but looks like it doesn't work. Or something I missed. 

It takes almost 15 seconds for debugging.

0

Hello Cem,

We are sorry to know to hear that you are running this performance issue. We delivered a bunch of improvements to the native debugger in 2024.2. Would you mind giving it a try and letting us know if that performs better?

If you notice no difference, would you mind sharing additional information as described below?

  • Recording that demonstrates the issue;
  • Use Help → Diagnostic Tools → Choose Trace Scenarios action and pick Debugger trace scenario
  • Reproduce the problem
  • Use Help → Collect Logs to generate the log archive
  • Disable the Debugger trace scenario
  • Upload it to the Upload Service and let me know upload ID.

Meantime, could you please try debugging your project through the xCode and compare if it performs much better in the similar scenario?

Have a nice day!

0

Dmitry Kazantsev 

Hello Dmitry,

Thanks for the quick response. You are right, it was the old version. After I upgrade it to 2024.2, there is noticeable difference. However, it is compared to IntelliJ IDEA a few second slower. If you want me to help for anything, feel free to ask me. 

0

Hello Cem,

I am glad to know you noticed performance improvements! Indeed, there is always a place for improvements and we constantly working on our native debugger. You might find this post interesting.

Have a nice day!

0

Please sign in to leave a comment.