Recently I was suffering from the sharepoint debugging. It was extremly slow - I dare to say around 15-20 minutes to load symbols.
I have tried to debug attaching to the process w3w.exe and also with Debugger.Launch() in code.
The surfing won't bring much - some recommend to load symbols from Microsoft to optimize the debugging. Tried - didn't help.
Finally on the second week of pain I came up with a quick and elegant solution - to use WSPBuilder to debug!
Here is the instruction to make the debugging enjoyable:
1. clear all old breakpoints (some people claimed that it really helped them to improve the debugging experience)
2. set the pool identity the same as the user who runs the debug (it will mitigate the message box "attaching to this process can potentially harm..")
3. Use the WSPBuilder extension for Visual Studio to put the ddl in GAC and recycle app pools
4. Run the site to initiate the process w3w.exe
5. Through WSPBuilder attach to IIS working processes
Note: Sometime even the visual studio shows that it runs the debug, the actual breakpoints are not hit. I don't know the reason. But I know how to cure such behavior - kill all w3w.exe process and re-attached to a new one which you will fire surfing the sharepoint site.