 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / Managed C++ / February 2005I am so frusterated with how slow MSVC is
I can't tell you how frusterated I and my coworkers are with "MSVC 7.1 .net 2003" (what am I supposed to call this thing anyway?). Compiling and linking take twice as long with "MSVC 7.1 .net 2003" than with MSVC 6. My coworkers are angry at "MSVC .net 7.1 2003" and they're angry at me for pushing it (due to better C++ compliance). The problem is so pronounced, I'm shocked that this message board isn't full of people complaining. My guess is that our project is somehow different and "MSVC 7.1 .net 2003" has an extra hard time with it. We have 68 projects with approx. 15 files in each project. We use wxWidgets. Also very frusterating is the way the IDE stops responding when doing things like a) preparing to compile b) compiling c) linking. Even starting the IDE is a painfull experience, but luckily I only do that a couple times per day. Not to mention that when I change one .cpp in one of my projects, "MSVC 7.1 .net 2003" slowly loops through all the projects to see if anything needs to be recompiled and does a very time consuming full link. Makes it very difficult to make quick changes and debug (unlike MSVC 6). If MSVC didn't have such a wonderful breakpoint/watch-window interface, we'd have moved to distcc builds on cygwin. Faster and the makefile approach allows for different configurations without putting togeter a billion .sln and .vcproj files (maintenance nightmare). I'm sorry to sound like a crank, but I am just so worked up and have to come vent every month or so. Rudy > I can't tell you how frusterated I and my coworkers are with "MSVC > 7.1 .net 2003" (what am I supposed to call this thing anyway?). [quoted text clipped - 8 lines] > with it. We have 68 projects with approx. 15 files in each project. We > use wxWidgets. It's the large number of projects in the solution that has the largest impact. The good news is that VS 2005 is back near the speed of VC6 for building. -cd > I can't tell you how frusterated I and my coworkers are with "MSVC 7.1 .net > 2003" (what am I supposed to call this thing anyway?). [quoted text clipped - 27 lines] > > Rudy The dependency checking for a build can be more or less fixed with a visual studio plugin http://www.workspacewhiz.com/FastSolutionBuild/FastSolutionBuildReadme.html The thing that really bugs me is that VS occasionally freezes for 4-8 seconds in the edtior when all I want to do is update a comment or something innocuous (rebuilding browse or intellisense info as far as i can tell for the entire project) CS [Wed, 26 Jan 2005 14:51:31 -0800]: >Also very frusterating is the way the IDE stops responding when doing things I heard something about this problem/fix being adjustable in the "next" version (but I'm not sure how many nexts have come and gone since then). Until then, this does the trick nicely, and no real effect on the total times, but a big difference in system response during. http://www.codeguru.com/Cpp/V-S/tips/comments.php/c439/?thread=4744  Signature40th Floor - Software @ http://40th.com/ iPlay : the ultimate audio player for PPCs mp3,mp4,m4a,aac,ogg,flac,wav,play & record parametric eq, xfeed, reverb: all on a ppc > CS [Wed, 26 Jan 2005 14:51:31 -0800]: >> Also very frusterating is the way the IDE stops responding when [quoted text clipped - 7 lines] > > http://www.codeguru.com/Cpp/V-S/tips/comments.php/c439/?thread=4744 Nifty little hack. For the benefit of other readers: The file offset in vcspawn.exe from vc7.1 is 0x113f. Now, if there was just such a hack for C# compilations too... but they don't use vcspawn. -cd CD- [Thu, 27 Jan 2005 06:52:51 -0800]: >The file offset in >vcspawn.exe from vc7.1 is 0x113f. Close, but not quite right. The link has the correct location. Signature40th Floor - Software @ http://40th.com/ iPlay : the ultimate audio player for PPCs mp3,mp4,m4a,aac,ogg,flac,wav,play & record parametric eq, xfeed, reverb: all on a ppc > CD- [Thu, 27 Jan 2005 06:52:51 -0800]: >> The file offset in >vcspawn.exe from vc7.1 is 0x113f. > > Close, but not quite right. The link has the correct location. 0x113f is where the entire code snippet referenced in the first posting begins. 0x1140 is where the single byte to change is located. Sorry for adding to the confusion - I had to re-read the page several times before I spotted the file offset - the more apparent offset shown is 0x401d3f which is clearly not a file offset. -cd > CS [Wed, 26 Jan 2005 14:51:31 -0800]: > >Also very frusterating is the way the IDE stops responding when doing [quoted text clipped - 3 lines] > effect on the total times, but a big difference in system response > during. Thanks for your help. In this case, by IDE I was refering to the integrated development environment - aka Visual Studio .net 2003 7.1's editor, scroll bars, find dialog, etc. It is this IDE that fails to respond during certain portions of the build phase. In my product the text editing logic (and associated scroll bar) runs in a seperate thread than the computation logic. That way while my app is computing, the user can still use the editor. I believe the Visual Studio 7.1 .net 2003 developers did not take proper care to seperate the functionality in their product. Anyways, my point is that while your tip helps other processes on my system run with higher priority with respect to the cl.exe and link.exe, it does not overcome the IDE responsiveness issue. Thanks, Chris >> >Also very frusterating is the way the IDE stops responding >> >when doing things [quoted text clipped - 9 lines] > I believe the Visual Studio 7.1 .net 2003 developers did not > take proper care to seperate the functionality in their product. Yes, unfortunately in VS2003 IntelliSense did acquire locks on the primary thread in some scenarios causing such intermittent hangs. We're working on removing these in VS2005. Thanks, SignatureTarek Madkour, Visual C++ Team This posting is provided "AS IS" with no warranties, and confers no rights. > Yes, unfortunately in VS2003 IntelliSense did acquire locks on the > primary thread in some scenarios causing such intermittent hangs. > We're working on removing these in VS2005. Hi Tarek, Thanks so much for your reply! Is there a way to disable IntelliSense? Would disabling IntelliSense eliminate the primary thread locking issue I describe? Thanks, Chris > Thanks so much for your reply! Is there a way to disable > IntelliSense? Would disabling IntelliSense eliminate the primary > thread locking issue I describe? One workaround is to delete feacp.dll which would totally disable intellisense and everything that's based on it (e.g. class view, some debugger breakpoint validation, some 3rd party plugins). Alternatively, you could make the .ncb file for the project read- only. Thanks, SignatureTarek Madkour, Visual C++ Team This posting is provided "AS IS" with no warranties, and confers no rights. It is true that dependancy checking is unneccesarily slow. We also found that VC7 has quite different performance characteristics compared to 6. For instance, if you include a header file that declares lots of constants that are object instances, such as CString constants, the 7.1 compiler is very slow. If you move such a file in a precompiled header, it compiles a lot faster (up to three times on our sources). I also recently found out that 7.1 has the capability to recompile a dll without rewriting the lib file. VC does this for two of our dlls, not surprisingly the ones which we recreated from scratch in VC7.1. It does not work for vcprojs converted from other visual studio versions. Who knows the secret project setting that affects this? Most of my build time is now spent watching VC rebuild dependent dlls for no reason. > It is true that dependancy checking is unneccesarily slow. Try Fast Solution Build. It's free and it's good. (Only the linker redirection ones gave us trouble. Uninstalling the thing and reinstalling it without linker redirection fixed this.) > We also found that VC7 has quite different performance characteristics compared to 6. > > For instance, if you include a header file that declares lots of constants that are object instances, such as CString constants, > the 7.1 compiler is very slow. If you move such a file in a precompiled header, it compiles a lot faster (up to three times on > our sources). We ran into this one, too. What helped was declaring the constants as 'extern' and compiled the definitions seperately in their own .cpp file. Parsing const declarations seems to be a lot faster than parsing const definitions and this way the definitions have to be parsed only once. > I also recently found out that 7.1 has the capability to recompile a dll without rewriting the lib file. VC does this for two of > our dlls, not surprisingly the ones which we recreated from scratch in VC7.1. It does not work for vcprojs converted from other > visual studio versions. Who knows the secret project setting that affects this? Most of my build time is now spent watching VC > rebuild dependent dlls for no reason. <plug> Have you looked at IncrediBuild? (www.xoreax.com) It distributes compilations over the network. We have recently evaluated it and found it to be very helpful. On one big project the build times on our (dedicated 2CPU) build machine went down from about 45mins to about 10mins. One small project I was recently working on built within 2:30mins instead of about 8mins. As I was working on some headers that are included everywhere, I was very happy that this came together with the evaluation. (It's fun to watch your project build on a dozen machines within a fifth of the time.) We're still undecided how many licenses we will buy. I am looking forward to the day this is settled. Just testing it made us all addicted. :) </plug> > [...] Schobi SignatureSpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "The presence of those seeking the truth is infinitely to be prefered to those thinking they've found it." Terry Pratchett Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.