Very Slow VSS Development

[md Webs Unlimited]

Using VSS 2008 Team Edition

When debugging a ASP.Net web site the compile seem fast but starting the
application in the web browser, using the development server with FF, takes
a very long time > 1.5 minutes in most cases -- the browser appears with the
following in the status bar waiting on Localhost. Watching the debug window
there seems to be a lot of temp ASP.NET (managed code) load messages.

The system is a dual Xeon 2.4 with 3gb of memory.

I'm I missing a setting?

Also, when using the designer it is very slow also, you can not type at any
reasonable speed.

 

[Cowboy \(Gregory A. Beamer\)]

Make sure your drive is defragmented, as that can slow things down. Also,
what RPM drive are you running. A 7200 RPM drive beats the snot out of a
5600 when there is disk swapping and can make a noticeable difference.

Another factor is how much of the site is in other libs, etc. and how they
are compiled (ngened, etc.). You are likely spending a lot of time JITting
the site, the libs, etc.

To speed this up, a bit, you can compile the libs and then reference the
compiled libs. You will still have JIT time, but it seems to go a bit faster
when I do thsi. It may or may not help you. Moving code from your site into
libs can also speed things up.

Another option, althought more involved, is to open the site in your browser
and then link VS debugger to that process. You will still experience some
JIT slowdown, but you will be hooked in a bit faster. Depending on the page
you are testing, this may make things MUCH faster.

Oh, and watch out for having multiple websites in a single solution. Even
though you are only debugging one, the fact you are dealing with others can
slow things down. not sure why this is, other than intial compile to MSIL,
but it seems to be that way (maybe I need to time it?).

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://gregorybeamer.spaces.live.com/lists/feed.rss

*************************************************
| Think outside the box!
|
*************************************************

 

[md Webs Unlimited]

Thank for responding.

The drives(2) are 500gb 7200 SATA at 300.

I concur that it is more than likely JIT but it seems like an awful long
time when you're debunking a simple little piece of code.

What I'm taking from your comments that this is a normal occurrence and that
I should not be alarmed.

I'll pull my data tier and compiling it to libs and see if that helps.

Thanks again.

--
Mike - FrontPage MVP '97 - '02
Expression Tools & Addin
http://www.j-moves.com
http://www.panemanager.com
FrontPage Tools & Addin
http://www.jbots.com
E-Commerce
http://www.candypress.com

Make sure your drive is defragmented, as that can slow things down. Also,
what RPM drive are you running. A 7200 RPM drive beats the snot out of a
5600 when there is disk swapping and can make a noticeable difference.

Another factor is how much of the site is in other libs, etc. and how they
are compiled (ngened, etc.). You are likely spending a lot of time JITting
the site, the libs, etc.

To speed this up, a bit, you can compile the libs and then reference the
compiled libs. You will still have JIT time, but it seems to go a bit
faster when I do thsi. It may or may not help you. Moving code from your
site into libs can also speed things up.

Another option, althought more involved, is to open the site in your
browser and then link VS debugger to that process. You will still
experience some JIT slowdown, but you will be hooked in a bit faster.
Depending on the page you are testing, this may make things MUCH faster.

Oh, and watch out for having multiple websites in a single solution. Even
though you are only debugging one, the fact you are dealing with others
can slow things down. not sure why this is, other than intial compile to
MSIL, but it seems to be that way (maybe I need to time it?).

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://gregorybeamer.spaces.live.com/lists/feed.rss

*************************************************
| Think outside the box! |
*************************************************