This project is read-only.

Slow in VS2010 when debugging

Topics: Customizing Orchard, General, Troubleshooting, Writing modules
May 19, 2011 at 11:09 AM


When I start Orchard from vs2010 with ctrl-F5 it is realy fast and good to work with. When I start it with debugging enabled I can fetch coffee between every page load. What could cause this, because this makes it impossible to def for it.


May 19, 2011 at 12:09 PM

It's a conspiracy by the coffee manufacturers ;)

But seriously, yeah it is a pain. I think some of the perf improvements currently appearing in the latest development work will mitigate this a lot, but I haven't tested them yet. What I find helps is if you start debugging, then hit the stop button and wait until the page loads which will be quicker. Then start debugging again, because it's not starting from scratch and dynamically compiling everything this time it's much quicker.

May 19, 2011 at 12:24 PM

I knew it ;)

Is it advisable and possible to work with a developement version (that potential has the performance fix)? I'm currently learning to work with Orchard and need it in a project somewhere in the next couple of weeks. Is there any date known when this fix would be released?


May 19, 2011 at 12:42 PM

The changes I'm talking about are all in the 1.x branch so should be considered relatively stable. There haven't been any breaking changes in that branch so it should be fine. I assume it will all be part of the 1.2 release which is probably a way off, unless they do an interim release to deal with various specific issues.

May 19, 2011 at 12:46 PM

Thanks, Ill pick up the 1.x branch and see how it works...

May 19, 2011 at 1:07 PM

I downloaded the 1.* branch. The weird part is that it showed V1.0.2.. Performance was still dead.

This makes it hard for me to really learn orchard (debugging/hacking/trying stuff out). Not sure if I will be able to use Orchard in this state.

May 19, 2011 at 1:30 PM

Follow randompetes advice. The framework does a ton of Reflection, and until it gets to where you want it to, it has to move through thousands of parts. It does help to have a powerfull machine.

Also it would be advisable to dig into the testing parts and work from there to hack/debug/try stuff out. There is not much to debug IMHO in a running orchard instance, start with you end goal in mind, explore by spiking out tests. Look at how components are linked in other parts of the tests and reuse.

So, unless an alternate is not selected properly or the theme is not rendered ( either you forgot the Admin or Theme attribute ) properly, there should not be very much that you can't accomplish via some sweet unit testing goodness.

May 19, 2011 at 1:34 PM
Edited May 19, 2011 at 1:35 PM

The machine shouldnt be the problem. Its a quad core, 8Gig of ram and 4 SSD's in raid 0.

But maybe I should indeed not work with the orchard source code but with a normal project and only if I really need to know what is going on dive in the source code. Or do I need the whole source to develop modules?


May 19, 2011 at 1:46 PM

Well, I work with a full source enlistment. And I'm developing about 10 modules simultaneously (no joke; they're various different components of Media Garden and Science Project).

Using the Start/Stop/Restart tactic lets me debug fairly painlessly when I need to. The thing is, Orchard is so complex that debugging can be a very abstract experience even once you get there, and sometimes it's better to just figure out from the Exception and Call Stack what's going on. Unit testing would be great but a lot of the work I'm doing is delving quite deeply into the Shapes system and dynamic objects and a lot of the time I have no idea where to even start with those kind of tests. Still, it's something I really need to get on top of! (Over the years I've developed somewhat bad habits when it comes to testing...)

May 19, 2011 at 2:24 PM

just a question Pete, what do you exactly with start/stop/restart tactic? Maybe i'm not doing the same thing as you do. What do you call fairly painless? At this moment from the frontend to the dashboard takesaround 20 seconds and switching panel in the dasboard takes another 20.

May 19, 2011 at 2:42 PM

- Press Start, wait until compile has finished (when the browser starts loading the page). At this point click stop.

- Wait until the page has loaded. At this point it's worth signing in and going to the Dashboard, it's quicker if you do it without debugging, and this causes various things to get cached by Orchard so it's quicker on subsequent actions.

- Press Start again. This time VS starts debugging without recompiling, and without the dynamic compilation process taking place in orchard. So you're in much quicker.

May 19, 2011 at 2:47 PM

Now I feel kind of stupid, but when I press stop, my browser also stops... Or should I load it in a seperate IE Window?

May 19, 2011 at 2:56 PM

For me, the browser carries on loading when I stop debug ... I'm using Cassini and VWD, don't know if there's a difference or just a setting somewhere.

May 19, 2011 at 8:30 PM

Just to give some additional info on this, it is getting investigated, including with the VS team. My strategy to work around this is to launch the site using CTRL+F5 and only attach the debugger when I need to, and detach it when I don't.

May 20, 2011 at 11:53 AM

@bertrand - one difficulty there is that VWD Express doesn't have the "attach to process" option (at least not since SP1, I'm sure it used to be there!)  Great to hear it's getting looked into anyway :)

May 20, 2011 at 6:05 PM

For people running in to this issue: Would you mind trying to remove the "Trust Level="Medium"" line from web.config of Orchard.Web and see if it makes a difference?



May 23, 2011 at 9:21 AM

Ill try this out this afternoon.


May 23, 2011 at 7:07 PM


When I remove the whole line of trust level (with the originUrl) from the web.config it becomes FAST :)

What I do right now (based on Pete's suggestion): I launch the project with F5 in the local IIS Web server (setting in the project config) without the browser starting up (setting in the project config). Then I launch the browser and let it load (takes some time). After it has loaded the page I login as admin. Then I stop debugging and let the browser open. Then I press F5 again in visual studio. From that moment on I'm a happy debugger :)

Thanks all!

May 23, 2011 at 7:31 PM

Another interesting thing: the VS Web Server is actually a little faster than IIS when debugging (but not otherwise).

May 23, 2011 at 7:35 PM
Edited May 23, 2011 at 7:40 PM

let me also test that ;)

May 23, 2011 at 7:35 PM

I'm not sure if this is the case, however in an mvc app I wrote in the past, the debugging slowness was due to the default view locator disabling caching when debugging.  So it was cranking along constantly looking for views.  Not sure if that is applicable in orchard, or how much customization you've done to the view locators.

May 23, 2011 at 7:40 PM
Edited May 23, 2011 at 7:45 PM

@betrandleroy: This could be confirmation bias but it seems indeed a little faster to me.

 Normal debugging also seems to work now faster, but due to initial loading every time it is better to start it seperate with the "Dont open a page. Wait for a request from an external application" option in the project config.

May 23, 2011 at 8:13 PM

Medium trust as the default in Orchard is very likely on its way out. We are keeping med trust compat of course (at least for now) but it won't be the default any more. (vote for it)

Jun 2, 2011 at 1:20 AM

I know that this post is a few months old but i have noticed that Orchard generates many exceptions during start up, if you allow Common Language Runtime Exceptions to be thrown, you will see what i mean.  Its slow when debugging because all those exceptions are displayed in the output window, most of these exceptions are related to medium trust.  By applying the fix it will resolve many of the exceptions

Jun 3, 2011 at 1:19 PM

Just switched to latest 1.x branch and I have to say performance is vastly improved, both debugging and in general startup time.

I also tried something else: disabling my virus scanner's file system protection. That also made a marked improvement. Of course I don't have any actual numbers, but it just feels way better; I was starting to hit some serious startup time problems on my dev machine with a lot of modules installed. Now things are reasonable again :)