Hello,
Today I worked with one of my developers on an interesting issue and I was wondering if anyone else has run into this problem.
The developer was working on a project in VS 2003, he would attempt to run a test application, which was a winform, in debug mode and VS would hang. The only way get out of this was to kill VS.
When working with him on the issue I noticed he had a large number of files open within VS so I closed all of them except for the winform. Once I did this the application ran fine.
Is there a limit to the number of files which can be open at one time within VS? I did not count the number of open files but my guess would be around 50. This seems like this would be a small upper limit.
Thanks in advance for any insight.
-
-
Have you applied all service packs?
-
I believe he is running SP1, I will verify once I get in touch with the developer.
-
rilter7 wrote:
Is there a limit to the number of files which can be open at one time within VS? I did not count the number of open files but my guess would be around 50. This seems like this would be a small upper limit.
Thanks in advance for any insight.
The limit is system based. If you have 512 MB of ram the limit would be different then 1 or 2 GB of ram. Its not really a VS limitation. Why would you need 50 files open at once anyways ?
Its a much safer practice to keep open only the files you are making
changes to or reviewing. Something tells me your exceeding this rule of thumb a little drastically.
Try opening 50 instances of IE or firefox tabs and watch your response time crawl as well. -
odujosh wrote: Why would you need 50 files open at once anyways
50 source-code text files open in VS (assuming they're all around 5KiB) shouldn't even bring a 256MB machine down. VS's RAM increases logarithmically for each source file open in the same project.
-
rilter7 wrote:Hello,
Today I worked with one of my developers on an interesting issue and I was wondering if anyone else has run into this problem.
The developer was working on a project in VS 2003, he would attempt to run a test application, which was a winform, in debug mode and VS would hang. The only way get out of this was to kill VS.
When working with him on the issue I noticed he had a large number of files open within VS so I closed all of them except for the winform. Once I did this the application ran fine.
Is there a limit to the number of files which can be open at one time within VS? I did not count the number of open files but my guess would be around 50. This seems like this would be a small upper limit.
Thanks in advance for any insight.
what kind of files?
code, forms, resources (like bitmaps etc...)
was the project in version control?
how much ram on the machine?
what addins are installed to VS ?
does the app use a local database (SQL or Access or?? )
what other app were running?
CPU speed?
type of CPU ?
OS ? (XP, PRO,HOME,X64,Vista/Vista x64 etc...)
all of them could affect the way VS was responding.
-
Thanks for all of you responses.
figuerres,
IBM ThinkPad T43.
what kind of files? code files, xml, xsl and one winform
was the project in version control? yes, VSS.
how much ram on the machine? 2 GB
what addins are installed to VS ? none
does the app use a local database (SQL or Access or?? ) It accesses a SQL server database but it never reached this point. It wouldn't even show the winform.
what other app were running? Filemon
CPU speed? 1.86 GHz
type of CPU ? Intel Pentium
OS ? (XP, PRO,HOME,X64,Vista/Vista x64 etc...) XP Pro SP2
I also verified that SP1 for Visual Studio has been installed. -
W3bbo wrote:

odujosh wrote:
Why would you need 50 files open at once anyways
50 source-code text files open in VS (assuming they're all around 5KiB) shouldn't even bring a 256MB machine down. VS's RAM increases logarithmically for each source file open in the same project.
Its is all the work it does in the background that is the problem. Think background saving for 50 open files or checking thereof.
I have seen Building tree structure messages in Windows XP when working with 2 TB of Data local and a few network drives. So never overlook the penalty of overegineering. -
odujosh wrote:

W3bbo wrote:

odujosh wrote:
Why would you need 50 files open at once anyways
50 source-code text files open in VS (assuming they're all around 5KiB) shouldn't even bring a 256MB machine down. VS's RAM increases logarithmically for each source file open in the same project.
Its is all the work it does in the background that is the problem. Think background saving for 50 open files or checking thereof.
I have seen Building tree structure messages in Windows XP when working with 2 TB of Data local and a few network drives. So never overlook the penalty of overegineering.
50 source code files wouldn't even tax a good processor's cache, let alone its memory. 50 files is a few grains of sand compared to the desert that would be 2 terabytes of data. -
JChung2006 wrote:

odujosh wrote:

W3bbo wrote:

odujosh wrote:
Why would you need 50 files open at once anyways
50 source-code text files open in VS (assuming they're all around 5KiB) shouldn't even bring a 256MB machine down. VS's RAM increases logarithmically for each source file open in the same project.
Its is all the work it does in the background that is the problem. Think background saving for 50 open files or checking thereof.
I have seen Building tree structure messages in Windows XP when working with 2 TB of Data local and a few network drives. So never overlook the penalty of overegineering.
50 source code files wouldn't even tax a good processor's cache, let alone its memory. 50 files is a few grains of sand compared to the desert that would be 2 terabytes of data.
Try opening 30 IE windows and call me in the morning. Never underestimate the cost of background tasks.
Thread Closed
This thread is kinda stale and has been closed but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.