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.