Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Orleans extreme slow when debuging #8427

Closed
montella1507 opened this issue May 9, 2023 · 21 comments
Closed

Orleans extreme slow when debuging #8427

montella1507 opened this issue May 9, 2023 · 21 comments

Comments

@montella1507
Copy link

Hi,

anyone experiencing issues with debugging on MacOS M2 / Rider?

Orleans is like 500x times slower when debugger is attached.

Orleans 7.0, .NET Core 7.0

@ghost ghost added the Needs: triage 🔍 label May 9, 2023
@montella1507
Copy link
Author

When i Detach debugger it runs normally afterward...

@ReubenBond
Copy link
Member

Is that 500x number measured or an estimate? Are you attaching a debugger to a Debug build of your application, or a Release build? I would expect it to be about 10x slower, but it depends on what you're doing. I'm also not familiar with the debugger on macOS. Maybe it's much slower.

@cmeyertons
Copy link
Contributor

It may be related to dotnet/runtime#38736 - I've seen this problem crop up in highly parallel, multi threading code, which Orleans naturally leans into.

@montella1507
Copy link
Author

Seems so! Thank you

Unfortunately i can confirm this:

This is extremely frustrating, and makes debugging barely functional.
It's quicker to debug using log statements.

So i hope it will get fixed soon

@slonopotamus
Copy link

We're also seeing this with .NET 6.0 + Orleans 3.6.2 and believe that dotnet/runtime#38736 is the root cause. And no, 500x is not an exaggeration.

@ReubenBond
Copy link
Member

ReubenBond commented May 16, 2023

It sounds like this is a Mac-specific issue. Please👍 that issue and/or respond to it to try to get it resolved. It looks like it has quite a few 'votes' already...

@montella1507
Copy link
Author

I Will try the performance on Windows then.

@montella1507
Copy link
Author

montella1507 commented May 25, 2023

@ReubenBond

Windows - JetBrains Rider- 10700k, 64GB RAM, 200 grains:

  • no debug 280 - 330ms
  • debug 1300 ms

macOS - JetBrains Rider- M2 Air , 24GB unified, 200 grains:

  • no debug - 300-370ms
  • debug - 22 000 - 37 000 ms

So it may be mac-specific issue

@mkuennek
Copy link

We also encountered this issue while evaluating Orleans, but for both Windows and MacOS. Really rough to use Orleans like this.

@ReubenBond
Copy link
Member

ReubenBond commented Dec 20, 2023

@mkuennek is performance under the debugger equally bad on Win & Mac? When you run under the debugger, are you also changing any other settings, such as log levels? Please add feedback (thumbs up, comment with info) to the original .NET runtime issue: dotnet/runtime#38736

EDIT: also, which debugger are you using on Windows, @mkuennek, is it VS or Rider?

@mkuennek
Copy link

@ReubenBond Without having any hard number I would say both Mac and Windows experience the same performance degradation. Both platforms start showing same types of warnings and errors(slow storage access, failing to activate grains). We do not change any other settings. Both runs were in Debug configuration with same log levels, etc.

Thank you for the feedback. Already voted in the mentioned runtime issue.

Both platform tests were done using the current version of Rider but we also had another developer using Windows with VS report this problem.

@ReubenBond
Copy link
Member

Thanks for the info, @mkuennek. Hopefully we can get this fixed in the .NET Runtime and/or debuggers. I'm not sure why this is more of an issue on mac than Windows. My inkling was that the issue was related to the way that Rider's debugger handles the notification, but if behavior is the same on Windows under VS (which I have not yet experienced), then perhaps that is not the case. I've asked for more information on the dotnet/runtime thread.

@mkuennek
Copy link

I just installed VS to check it myself. The behavior is the same as with Rider.

If you think a small project for reproducing this issue could help, I can try providing one.

@ReubenBond
Copy link
Member

Thanks. The dotnet/runtime thread has a minimal repro already. The problem seems to be well understood by the runtime engineers and we're just waiting for a fix now.

@bc3
Copy link

bc3 commented Jan 10, 2024

hello, not on the orleans project, but i have a sort a like issue in our repository (private). I reported this today to Jetbrains: https://youtrack.jetbrains.com/issue/RIDER-104266/Blazor-server-app-performs-very-slow-when-run-from-debugger-on-Mac-M2 , add upvotes or something :D

@yoDon
Copy link

yoDon commented Feb 1, 2024

Adding my vote to the "please address this incredibly important issue" counter.

I just lost several days to this issue, trying to understand why my code was suddenly unusably slow. The batch job I was running takes 3x longer than normal when running under the debugger.

I'm running Rider IDE on a Mac M3 Pro.

@gaoyang
Copy link

gaoyang commented Feb 1, 2024

@bc3
Copy link

bc3 commented Feb 22, 2024

@gaoyang , @yoDon : i've downloaded EAP JetBrains Rider 2024.1 EAP 5 => see my info in the thread on the jetbrains forum https://youtrack.jetbrains.com/issue/RIDER-104266/Blazor-server-app-performs-very-slow-when-run-from-debugger-on-Mac-M2#focus=Comments-27-9227967.0-0

@ReubenBond
Copy link
Member

A fix has just been merged into dotnet/runtime!

@yoDon
Copy link

yoDon commented May 7, 2024

For those watching or encountering this, note that the merged fix is for .NET 9 not .NET 8

@ReubenBond
Copy link
Member

For those watching or encountering this, note that the merged fix is for .NET 9 not .NET 8

Correct. Noah made a comment about it here: dotnet/runtime#101864 (comment)

If you'd like to try this out, you can install a .NET 9.0 nightly build from here: https://github.com/dotnet/installer?tab=readme-ov-file#table

I will close this now, since the runtime issue is fixed. Please feel free to open a new issue referencing this if you hit similar symptoms.

@github-actions github-actions bot locked and limited conversation to collaborators Jun 16, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

8 participants