Let me guess: you have some kick-ass high-end computer with twenty gigamegaflops of solid state quantum GPU, but debugging an Orchard instance is slow. Particularly starting debugging (and spinning up an Orchard instance) is slow and when opening a page that wasn't yet hit by the JIT compiler is also slow. Meanwhile your computer uses a fraction of its resources.

One surprisingly simple way of speeding things up is the one Wolf advised me (it's a shame that I haven't thought about this myself...): setting the priority of the responsible processes higher. Actually there are a handful of processes that take part in running a site locally, so rising their priority level could give a performance boost:

• Depending on how you run the site:
  
  • w3wp.exe (IIS Worker Process): it runs if the site is deployed to IIS; also msvsmon.exe (Visual Studio Remote Debugging Monitor): when debugging on a local IIS instance, this tends to eat up a good portion of CPU; let it eat even more!
  • iisexpress.exe (IIS Express Worker Process) if deployed to IIS Express
  • WebDev.WebServer40.exe (Visual Studio Devserver) if running through the built-in server
• sqlservr.exe (SQL Server): if a local SQL Server is used
• devenv.exe (Visual Studio): practically every time

You can even permanently set priorities with the Prio tool.

Edit: a valuable tip from Bertrand Le Roy: when debugging on an IIS instance not starting it simply with F5, but attaching the debugger to an already running IIS Worker Process makes an enormous difference. Anybody telling me why this happens wins a one-year premium RSS subscription to the blog.

Edit 2: be careful that the above tip only works if you don't mess things up with starting the Orchard instance with F5. In my experience, even if you stop the debugger after that and restart VS, even IIS, you're doomed: only a Windows restart helps... The correct way is to only start the debugger by attaching it to the IIS process.

Happy debugging!

No Comments

• Bertrand Le Roy said 11 years ago

  My guess would be that when you F5-debug, VS builds, tears down the process, restarts it, which takes time ordinarily, but even more when a debugger is attached. When you attach the debugger on an already running process, you eliminate all that.

• Piedone said 11 years ago

  This can well be. What I still don't understand why for the last 30% of the time waiting for debugging to start is my computer idle. No CPU usage, no disk or network I/O.

• Wolf said 11 years ago

  In my case, giving the worker process Realtime priority reduced the compile time for this site from 30 seconds to 10 seconds.