Large Projects and developer studio
-
We are using Developer Studio 6.0 and Visual Source Safe 6.0. Our project consists of about 28 projects, each of which builds a DLL. We have also set up dependencies between the projects (via the workspace). As our project has gotten bigger, developer studio has continued to run slower. For example, attempting to start the application under the debugger (Go - F5), developer studio spends 40+ seconds "spinning" until the application actually launches. This delay also occurs after making a change and trying to compile. This delay really slows down our productivity, something must be done! My question to you all is, how are you managing large projects? I suspect the delay is being caused by the project dependencies, or just the large ammount of source it has to check for modifications (in case it needs to recompile). Some ideas are: 1) Break the workspace up into smaller workspaces, each with a few projects. 2) Get rid of the project dependencies and manage this manually 3) Switch to makefiles Thoughts? Chris Hafey
Hmmmm, it sounds like you have a case of the "ever growing .NCB file". Close your workspace, delete this nasty file, and see if it makes a difference. As far as I've been able to tell this file is only good for keeping stuff such as the "Working directory" and "Program arguments" which are set in the Debug tab of the Project Settings box. So if you've manually set those, you'll need to do it again after you delete the file; no big deal when you consider the performance gain. I hope it does it for you. Regards, Alvaro
-
We are using Developer Studio 6.0 and Visual Source Safe 6.0. Our project consists of about 28 projects, each of which builds a DLL. We have also set up dependencies between the projects (via the workspace). As our project has gotten bigger, developer studio has continued to run slower. For example, attempting to start the application under the debugger (Go - F5), developer studio spends 40+ seconds "spinning" until the application actually launches. This delay also occurs after making a change and trying to compile. This delay really slows down our productivity, something must be done! My question to you all is, how are you managing large projects? I suspect the delay is being caused by the project dependencies, or just the large ammount of source it has to check for modifications (in case it needs to recompile). Some ideas are: 1) Break the workspace up into smaller workspaces, each with a few projects. 2) Get rid of the project dependencies and manage this manually 3) Switch to makefiles Thoughts? Chris Hafey
Yes it probably is the project system attempting to scan the dependencies of your project. One possible solution to this is to try to reduce the complexity of your code. There is a good book on this "Large Scale C++ Development" I think is the name. Its a few years old and only a little out of date, but I found it useful when it came to compile time complexity issues. The check list of easy things to do to reduce this scan time is ... Check to make sure none of the h files are on network drives Check to makesure every path on your include path (tools.options.directories) exists, and that there are no duplicates. Try moving more headers into your pch files. Check if you are using the /Gm compiler switch and remove it. ( mimimum rebuild, the IDE will automatcally throw /FD instead if you get rid of /Gm, and scanning a /FD created idb file is faster ) Take a look at your h files and declare some of them "system headers" so they don't get timestamp checked, do this by adding those files to the "sysincl.dat" file. Always backup your sysincl.dat file before modifying it. Eliminate some of the header files from your sysincl.dat that you "know" you don't use. Be careful if you do this, you might be including them and just not know it, if you remove entries and you were using them, this will actually make things slower. Always backup your sysincl.dat file before modifying it, just in case. I have a couple of other tricks that might work if this doesn't work. Hope this helps :) KiP int f,r,a,c,t,A,l=42;main(){while(--l>-42)for(t=-60;t++<20;putch('J'-f))for(A=a=r=f=0;++f<42&&r*r+A*A<7056;c=r+t,a=l+A,r=(c*c-a*a)/42,A=c*a/21);}
-
We are using Developer Studio 6.0 and Visual Source Safe 6.0. Our project consists of about 28 projects, each of which builds a DLL. We have also set up dependencies between the projects (via the workspace). As our project has gotten bigger, developer studio has continued to run slower. For example, attempting to start the application under the debugger (Go - F5), developer studio spends 40+ seconds "spinning" until the application actually launches. This delay also occurs after making a change and trying to compile. This delay really slows down our productivity, something must be done! My question to you all is, how are you managing large projects? I suspect the delay is being caused by the project dependencies, or just the large ammount of source it has to check for modifications (in case it needs to recompile). Some ideas are: 1) Break the workspace up into smaller workspaces, each with a few projects. 2) Get rid of the project dependencies and manage this manually 3) Switch to makefiles Thoughts? Chris Hafey
There are two basic ways to deal with this problem: 1. Always "unload" any project you're not working with at the moment, this will greatly reduce dependancies. Right click on the other projects and choose "Unload" and then you don't have to deal with it. 2. Don't use the Dev Studio facility for this. It's fine to use various projects locally, but create a new project to build everything, and then export it as a makefile. Also make sure you're using the latest service pack, as various fixes have been made to this, disable the "Wizard Bar", and reduce dependancies by making sure you have only the .h files you absolutely need.
-
Hmmmm, it sounds like you have a case of the "ever growing .NCB file". Close your workspace, delete this nasty file, and see if it makes a difference. As far as I've been able to tell this file is only good for keeping stuff such as the "Working directory" and "Program arguments" which are set in the Debug tab of the Project Settings box. So if you've manually set those, you'll need to do it again after you delete the file; no big deal when you consider the performance gain. I hope it does it for you. Regards, Alvaro
The working directory and program arguments are stored in the .opt file. The .ncb stores information for classview and intellislow... sorry intellisense ;) It's worth remembering that some of the sourcesafe integration information is stored in the .opt file as well as .dsp and .dsw. I've spent some time finding out why visual studio kept attaching to a sourcesafe project when there was no information about sourcesafe in the project and workspace files.
-
The working directory and program arguments are stored in the .opt file. The .ncb stores information for classview and intellislow... sorry intellisense ;) It's worth remembering that some of the sourcesafe integration information is stored in the .opt file as well as .dsp and .dsw. I've spent some time finding out why visual studio kept attaching to a sourcesafe project when there was no information about sourcesafe in the project and workspace files.
-
We are using Developer Studio 6.0 and Visual Source Safe 6.0. Our project consists of about 28 projects, each of which builds a DLL. We have also set up dependencies between the projects (via the workspace). As our project has gotten bigger, developer studio has continued to run slower. For example, attempting to start the application under the debugger (Go - F5), developer studio spends 40+ seconds "spinning" until the application actually launches. This delay also occurs after making a change and trying to compile. This delay really slows down our productivity, something must be done! My question to you all is, how are you managing large projects? I suspect the delay is being caused by the project dependencies, or just the large ammount of source it has to check for modifications (in case it needs to recompile). Some ideas are: 1) Break the workspace up into smaller workspaces, each with a few projects. 2) Get rid of the project dependencies and manage this manually 3) Switch to makefiles Thoughts? Chris Hafey
I'll second the vote for "Large Scale C++ Software Design" by Lakos. Minimize include file dependancies. Ensure include files have conditionals within them so they are iincluded once. Minimize class interdepancies. Use pointers to classes for class members, instead of an instance of the class itself within other classes. I've also found significant differences in performance with faster machines and Windows 2000 vs. W98. ie. My 300Mhz Notebook running W98 is a dog to use with VC, whereas my W2K 550Mhz P3 flies in comparison. One thing that recently started happening is whenever I switch back to VC after editing outside of it, VC goes and updates dependancies all on its own. This is causing me some frustration as its slow and a waiste of (my) time. I don't know what triggered this, as it never used to happen I'm sure. Neville Franks, Author of ED for Windows http://www.getsoft.com
-
We are using Developer Studio 6.0 and Visual Source Safe 6.0. Our project consists of about 28 projects, each of which builds a DLL. We have also set up dependencies between the projects (via the workspace). As our project has gotten bigger, developer studio has continued to run slower. For example, attempting to start the application under the debugger (Go - F5), developer studio spends 40+ seconds "spinning" until the application actually launches. This delay also occurs after making a change and trying to compile. This delay really slows down our productivity, something must be done! My question to you all is, how are you managing large projects? I suspect the delay is being caused by the project dependencies, or just the large ammount of source it has to check for modifications (in case it needs to recompile). Some ideas are: 1) Break the workspace up into smaller workspaces, each with a few projects. 2) Get rid of the project dependencies and manage this manually 3) Switch to makefiles Thoughts? Chris Hafey
Interesting thread, I have 800,000+ lines of C++ in my workspace, divided amoungst 20 projects. I would like help (who wouldn't). I find that as soon as I start to edit a dialog it then takes maybe 30 seconds for each change - for example adding a new control. I get the impression that this started after I added the web control. This is only dialogs - adding code etc. is just fine. Again: I do anything on a dialog and the CPU goes up to 100% for maybe 30 seconds. Any suggestions? Old Simon HB9DRV
-
I'll second the vote for "Large Scale C++ Software Design" by Lakos. Minimize include file dependancies. Ensure include files have conditionals within them so they are iincluded once. Minimize class interdepancies. Use pointers to classes for class members, instead of an instance of the class itself within other classes. I've also found significant differences in performance with faster machines and Windows 2000 vs. W98. ie. My 300Mhz Notebook running W98 is a dog to use with VC, whereas my W2K 550Mhz P3 flies in comparison. One thing that recently started happening is whenever I switch back to VC after editing outside of it, VC goes and updates dependancies all on its own. This is causing me some frustration as its slow and a waiste of (my) time. I don't know what triggered this, as it never used to happen I'm sure. Neville Franks, Author of ED for Windows http://www.getsoft.com
95/98 are very slow to start VC projects, compared to NT/2K - something to do with file mod-date access time, i think. -c ------------------------------ Smaller Animals Software, Inc. http://www.smalleranimals.com
-
I'll second the vote for "Large Scale C++ Software Design" by Lakos. Minimize include file dependancies. Ensure include files have conditionals within them so they are iincluded once. Minimize class interdepancies. Use pointers to classes for class members, instead of an instance of the class itself within other classes. I've also found significant differences in performance with faster machines and Windows 2000 vs. W98. ie. My 300Mhz Notebook running W98 is a dog to use with VC, whereas my W2K 550Mhz P3 flies in comparison. One thing that recently started happening is whenever I switch back to VC after editing outside of it, VC goes and updates dependancies all on its own. This is causing me some frustration as its slow and a waiste of (my) time. I don't know what triggered this, as it never used to happen I'm sure. Neville Franks, Author of ED for Windows http://www.getsoft.com
I read the book about 4 years ago -- about 6 months after I figured out much of what was written in it....too bad I didn't see it sooner! Anyway, I avoid placing #include "" statements in header files whenever possible, and I seem to think that they suggest the same. This will improve the load time of MSDev when loading, but I also know that when I did this in a workspace which was made up of only projects, it took a couple days to go through everything....so if you choose to go this route, its going to be a bit of boring, slow, tedious work.
-
Interesting thread, I have 800,000+ lines of C++ in my workspace, divided amoungst 20 projects. I would like help (who wouldn't). I find that as soon as I start to edit a dialog it then takes maybe 30 seconds for each change - for example adding a new control. I get the impression that this started after I added the web control. This is only dialogs - adding code etc. is just fine. Again: I do anything on a dialog and the CPU goes up to 100% for maybe 30 seconds. Any suggestions? Old Simon HB9DRV
-
We are using Developer Studio 6.0 and Visual Source Safe 6.0. Our project consists of about 28 projects, each of which builds a DLL. We have also set up dependencies between the projects (via the workspace). As our project has gotten bigger, developer studio has continued to run slower. For example, attempting to start the application under the debugger (Go - F5), developer studio spends 40+ seconds "spinning" until the application actually launches. This delay also occurs after making a change and trying to compile. This delay really slows down our productivity, something must be done! My question to you all is, how are you managing large projects? I suspect the delay is being caused by the project dependencies, or just the large ammount of source it has to check for modifications (in case it needs to recompile). Some ideas are: 1) Break the workspace up into smaller workspaces, each with a few projects. 2) Get rid of the project dependencies and manage this manually 3) Switch to makefiles Thoughts? Chris Hafey
use 1 & 2. if we want an incremental or full build we use scripts to invoke msdev to build each script. If just working on a few DLLs, we do that by loading .dsps into a workspace. More .dsps the slower the process. I'm working on a project a lot bigger than the one you describe. Same problems, just scales even worse - plus eventually you'll load so many .dsps that dev studio will crash when you do a 'save all'. Stephen Kellett -- C++/Java/Win NT/Unix variants Memory leaks/corruptions/performance/system problems. UK based. Problems with RSI/WRULD? Contact me for advice.
-
If you had tried to do similar stuff on Visual Cafe/JBuilder you'd feel yourself in heaven with only 40 sec delay. LOL. Serious!!! I'd go for smaller workspaces and minimum dependencies and move some stuff in static libs (instead of DLL's b/c DLL take longer to load). Just my two cents. :) ;) ;P :-D :cool: Farhan Noor Qureshi
I'll agree with that. As well as my VC++ work I do work for a blind-related project, and we use Visual Cafe for that. IS that slow or what? Stephen Kellett -- C++/Java/Win NT/Unix variants Memory leaks/corruptions/performance/system problems. UK based. Problems with RSI/WRULD? Contact me for advice.