none
Edit and Continue slow after making a change

    Question

  • When I hit a breakpoint and make a change then continue (F10) it hangs for about 20 seconds.  My project worked fine in Visual Studio 2013. I have noticed that the bigger my project is, the slower EnC is. I have a few projects in my solution that vary in size and the smaller projects are much faster when changing code during debugging. 

    Specs:
    Windows 10 Anniversary update. (Also tried it on another machine with windows 7, same issue)
    Visual Studio 2015 update 3
    .net 4.6.2
    VB.NET for most of the projects, some projects in the solution are C#.
    WinForms app.
    TFS

    Any suggestions would be great as this is slowing us down!

    Thursday, February 9, 2017 6:16 PM

All replies

  • Good question, there could be a number of reasons, in new versions of Visual Studio, more calls could be made to CLR to get the specific information needed to run your application and debug. Possibly, with the newer version there are more features running in the background causing the slowdown.

    Another alertnative is turning on debug only your code in the settings.

    These links might help:

    Enabling Just My Code (use this to debug just your code).

    https://msdn.microsoft.com/en-us/library/dn457346.aspx

    Getting Started with Debugging

    https://msdn.microsoft.com/en-us/library/dn986851.aspx

    Hope that helps!

    Thursday, February 9, 2017 6:23 PM
  • Hi jpro1000,

    Like Juan Davila's suggestion, really there are different reasons that debugging can be slow, and make this particular item not directly actionable.

    This blog shared some steps which could make debugging faster:

    https://blogs.msdn.microsoft.com/visualstudioalm/2015/03/03/make-debugging-faster-with-visual-studio/

    If possible, you could check them, I think it could improve the debugging function.

    Best Regards,

    Jack


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Friday, February 10, 2017 2:31 AM
    Moderator
  • Hi guys,

    I reviewed all those settings and still slow. The last post by Jack-Zhai mentioned it says that Edit and Continue (EnC) has to validate if the change is permitted by EnC and could take some time. Is there a way I can see why that might be the case and how to improve parts of the code that might slow this down?  Also, VS 2017 is coming out soon I'll try that to see if it's faster. What iss odd is that VS 2013 ran fine on this project. Are there some MSBUILD settings or configs I can tweak to match vs 2013

    James

    Monday, February 13, 2017 9:49 PM
  • Hi James,

    >>Is there a way I can see why that might be the case and how to improve parts of the code that might slow this down?

    We often use the VS profiler tool to analyze the functions performance:

    https://msdn.microsoft.com/en-us/magazine/dn973013.aspx

    https://msdn.microsoft.com/en-us/library/ms182372.aspx

    >>Are there some MSBUILD settings or configs I can tweak to match vs 2013.

    Maybe you could find the differences in the .xxxproj file between the two versions.

    Best Regards,

    Jack


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Wednesday, February 15, 2017 10:55 AM
    Moderator
  • Hi James,

    Would you please share the latest information? Do you resolve this issue now?

    We would appreciate it if you could provide the latest progress for this issue:)

    Best Regards,

    Jack


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.



    Tuesday, February 21, 2017 2:31 AM
    Moderator
  • I have noticed the same thing with my visual studio projects. My company is in the process of upgrading from VS 2010 to VS 2017.

    When I make a change in VS 2010 and hit F5, it *literally* takes less than 0.5 second to continue debugging. But then when I open the same project in VS 2017, it takes 5-10+ seconds to continue.

    In one particular file, when I make a change, it takes over 2 minutes to continue debugging. I suspect this may caused by some older dlls or VB6 COM issues with this particular file. But whatever the cause, it was instantaneous in VS 2010.

    Every release of VS makes EnC slower and slower, and it seems to allow fewer changes. In VS 2010 (VB.NET) we can make changes to a method which contains a Static variable and then continue. But now EnC forces a stop and rebuild (why? who knows...)

    Wednesday, April 19, 2017 3:04 PM
  • I've had these same issues in several classes in my projects at work. It's really frustrating. There's one specific class that takes a minute and 20 seconds to continue after adding just a space to the code. Another class takes 10 seconds almost every time. Sometimes it's completely random. I'll make a small change, F10, and it continues immediately. Back up 2 lines, make another small change, F10, 20 seconds while VS hangs.

    I spent HOURS upon HOURS with Microsoft support trying to resolve this issue, especially with the class that takes over a minute to continue. The only thing they can do is take our entire project and set it up in their lab, which is difficult to do. They've looked at giant dump files, only to tell me things I already know.

    Drives me nuts that it's faster to stop debugging and restart the app, than use EnC sometimes. Grrrrrrrr..... This all started in VS2015, and still exists in VS2017. Might even be worse in 2017.
    Tuesday, November 21, 2017 4:11 PM
  • I have this all the time, all day long for a long time already. I also feel that it's even worse in VS 2017.

    I can edit and continue a handful of times and then I have to restart Visual Studio, because the IDE starts freezing 20-30 seconds whenever I hit continue after an edit. But restarting is so inconvenient that it makes Edit and Continue almost unusable.

    With every update of Visual Studio I hope it's fixed (running version 15.5.4 now), but alas it never is.

    Thursday, January 25, 2018 2:02 PM
  • Have you considered any hardware issues? From my understanding once VS is ran a couple times, it tends to run faster not slower. I would consider a SSD for install VS or maybe even SSHD. Performance lost in VS can be noticed early on, though once things get set in memory VS tends to start up and load faster at the least.

    Tuesday, February 13, 2018 7:57 PM
  • I have the same problems, my process in VS2017 freezes after every edit and continue, and the Single-Stepping code (local code, my source) is practically unusable, many times the whole VS2017 shuts down, and restarts, saying "sending to MS an information about the problem" blah blah!.

    Having done my complaints on this forum few days ago, no one  answered my concern.

    Yielding VS 2017 as unusable for larger projects! (like mine) >500k lines of code, 40 projects, 900 classes.

    Seems that every new version is slower than the former...

    ¿any clue?


    Monday, March 5, 2018 2:50 PM
  • I have the same problem with Edit and Continue and it is very easy to replicate and Microsoft should try to fix this ASAP. if you have a small subroutine with say 15 to 20 lines of code the performance is fine. As the routines get bigger the edit and continue run slows down. What I do is have a small subroutine that I put my new code in and debug there and then move it to my larger  routines after it is debugged (not easy to do with older code).

    My guess is this is what happens in edit and continue mode:

    The compiler checks the code sequentially against intellisense starting at the beginning of a sub or function that has been edited. So if you had a function that has 500 lines, it is checking each of these lines instead of being smart enough to track only the line numbers that have changed since the last application run.   The same performance issue is occurring with setting  breakpoints. Instead of tracking breakpoints by line number in the code document, VS starts at the beginning of the function and appears to be running unnecessary background routines that have nothing to do with the simple operation of setting breakpoints. 

    Very, very frustrating. Would probably take a week or less to fix the problem if they put their minds to it. 

    • Proposed as answer by Juan Davila Wednesday, October 31, 2018 4:13 AM
    Wednesday, October 17, 2018 4:42 AM