Multi-core CPUs on machines have gotten fast enough over the
past few years that in most common application scenarios you don't usually end
up blocking on available processor capacity in your machine.
What you are much more likely to block on is the Seek and
I/O speed capacity with which your computer accesses your hard drive. If
you are using an application that needs to read/write a lot of files, it is not
atypical for your CPU processor utilization to be really low - since the
application might be spending most of its time just waiting for the disk
operations to complete.
When you are doing development with Visual Studio you end up
reading/writing a lot of files, and spend a large amount of time doing disk I/O
activity. Large projects and solutions might have hundreds (or thousands)
of source files (including images, css, pages, user controls,
etc). When you open a project Visual Studio needs to read and
parse all source files in it so as to provide intellisense. When you are
enlisted in source control and check out a file you are updating files and
timestamps on disk. When you do a compilation of a solution, Visual
Studio will check for updated assemblies from multiple disk path locations,
write out multiple new assemblies to disk when the compilation is done, as well
as persist .pdb debugger symbol files on disk with them (all as separate
file save operations). When you attach a debugger to a process (the
default behavior when you press F5 to run an application), Visual Studio then
needs to search and load the debugger symbols of all assemblies and DLLs for
the application so as to setup breakpoints.
If you have a slow hard-drive, Visual Studio will end up
being blocked as it waits for it to complete these read/write operations -
which can really slow down your overall development experience.