Hi Tony,
This sounds like the same issue we are having on our major project (a
WPF/CAB project). Our Client solution has 66 project files in the
solution, and our middle tier has 77 project files. We are running on
Windows XP 32bit SP3. And yes, Visual Studio (2008) starts falling
apart visually before finally collapsing due to lack of RAM (swap space
makes no difference).
Because of this issue we discovered that XP has an upper limit of usable
RAM because it's 32 bit. After a 32bit Windows OS boots up, it has a
maximum RAM of 4GB minus any RAM hardware on PCI slots use. For
example, despite having 4GB or RAM installed, we average around 2.8Gb
available after boot (this is what you see on My Computer | Properties |
General tab). Throwing in more RAM won't help.
The best solution would be to move up to a 64bit OS which has a much
higher RAM maximum, and can use all available RAM (I recommend Windows 7
64bit). Unfortunately for us, that's out of the question because we're
hamstrung by the corporate Standard Operating Environment. I've been
pushing hard for our SOE to be shifted (even if only for IT), but
progress is too slow for us.
We've had great success in running cut-down solutions that only contain
the projects we need. Some of our team built a solution generator using
the main solution file as a source, while others (like me) like to hand
build our cut-down solutions. The smaller solutions cope much better
memory wise and have reduced the number crashes. We also unload
projects from our cut-down solutions to further reduce memory impact
(however the savings aren't really used until you restart VS).
The disadvantage of this is it code synchronisation can be tricky, and
puts more onus on the developer to coordinate changes themselves. i.e,
if another developer makes changes in a project you have checked out and
you pick up part of their change, your solution probably won't build.
We get around this by having batch files to compile the full solution,
and by doing regular "Get Latest" on the full code branch. Our
continuous integration build helps highlight any other code sync issues.
Watch out for VS Add-ins and patches too. Some of our developer
environments have had problems with certain Add-ins while others haven'
t. Some developer environments also react differently for no apparent
reason and require patches from MS.
Another thing to note; watch your VS integrated source control provider.
We recently switched from Vault to TFS and have realised since that
Vault caused huge memory leaks in VS. We were stuck on a slightly older
version of Vault than is available, but it seems TFS is much better at
handling memory inside VS. e.g. our full solution in VS, once loaded
and compiled, uses over 100Mb less memory on TFS than Vault. devenv.exe
also opens and closes a hell of a lot quicker using TFS, and has never
had an instance hanging around in the background since moving to TFS.
I'm sure the most optimal solution would be Windows 7 64bit with 8Mb RAM
and cut-down projects. Not sure if VS2010 has better memory usage yet.
Good luck!
Carl.
Carl Scarlett
Senior .NET/WPF Developer, UX Designer - Genesis Team
IT Applications Delivery | Bankwest
A: Level 5, 199 Hay Street | Perth | Western Australia | 6004
P: (08) 9449 8703
M: 0408 913 870
E: [email protected]
From: [email protected]
[mailto:[email protected]] On Behalf Of
[email protected]
Sent: Friday, 23 July 2010 8:21 AM
To: [email protected]
Subject: Out of memory exceptions in VS2010 with Silverlight 4
Hi all,
It's Friday, so I thought I would let you know about one issue in our
team.
Basically, we are running 32-bit Windows XP. The machines have anywhere
between 2 and 4GB
RAM. Everyone in the team gets System Out Of Memory Exceptions. When
that happens, you have
wasted the compile time, and then you have to shut down VS2010, start it
up, then open up the
solution. The solution has a significant number of projects in it.
Apparently this problem only
happens in 32-bit windows.
So for the whole restart process, we have assigned 10 minutes to this
procedure.
Next we have logged the total crash time for our team of 7 developers
(some days people were
away, but it ultimately doesn't matter).
The times lost are as follows:
14th 240 mins
15th 100 mins
18th 120 mins
19th 60 mins
20th 200 mins
21st 100 mins
22nd 140 mins
we have assigned an arbitrary value against the times of $100/hour. So
the loss of productivity is
16 hours @ $100/hour = $1600.
Hopefully soon these figures will become a significant enough figure to
justify an upgrade!
Regards,
Tony
_______________________________________________
ozsilverlight mailing list
[email protected]
http://prdlxvm0001.codify.net/mailman/listinfo/ozsilverlight
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
________________________________________________________________________
_______
This email has been scanned by the Bankwest Email Security System.
________________________________________________________________________
_______
_______________________________________________________________________________
Unencrypted electronic mail is not secure and may not be authentic.
If you have any doubts as to the contents please telephone to confirm.
This electronic transmission including any attachments is intended only
for those to whom it is addressed. It may contain copyright material or
information that is confidential, privileged or exempt from disclosure by law.
Any claim to privilege is not waived or lost by reason of mistaken transmission
of this information. If you are not the intended recipient you must not
distribute or copy this transmission and should please notify the sender.
Your costs for doing this will be reimbursed by the sender.
We do not accept liability in connection with computer virus, data corruption,
delay, interruption, unauthorised access or unauthorised amendment.
_______________________________________________________________________________
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
_______________________________________________
ozsilverlight mailing list
[email protected]
http://prdlxvm0001.codify.net/mailman/listinfo/ozsilverlight
