LP on .NET

August 7, 2007

.NET Garbage Collection

Filed under: .NET,technology — Larry Parker @ 12:41 am

My app was in the final stages of testing last week, and we ran a home-grown load tester that simulated thousands of hits to a .NET 2.0 Windows service via a socket call (much higher than would ever take place).  Everything worked fine, but memory usage in Task Manager for the service spiked at 110 mb and stayed there (normal memory usage was 20-25 mb).  It made sense that it would go up temporarily since an in-memory Xml document was being built based on the packets sent during the load test.  But it was surprising that it didn’t come back down at some point when the garbage collector kicked in.

I checked my app for any references that might be holding on to the Xml document, and everything looked ok.  Then a colleague suggested that I take a look at the GC class in the System namespace, and I found the static method Collect which forces garbage collection to take place:

    GC.Collect();

The next time I ran the load tester, memory spiked as expected but then came down after I forced garbage collection.  I would assume this method has a cost associated with it, and your app could thrash if it’s executed too frequently (.NET probably leaves some memory padding to avoid subsequent thrashing), so finding a strategic place for it would make sense.  In my case, it was after the Xml document was persisted to the file system and I no longer needed the in-memory document.

Anyway, I hope this helps anybody else who sees the Mem Usage column in Task Manager go up and not come down for their .NET apps.

Advertisements

August 4, 2007

VSTS and Team Foundation Server

Filed under: .NET,technology,TFS,Visual Studio,VSTS — Larry Parker @ 1:03 pm

I have been using Visual Studio Team Systems & Team Foundation Server for source code control for a couple of projects this year.  So far so good, but it wasn’t until last Friday that I really took a liking to it.

I needed to reorganize my team project’s folder structure (our trunk) and then branch off the trunk so we could have a copy for maintenance and continue on with our main development.  Although I was a bit hesitant to start moving folders around on the server, TFS really did a good job at it.  Definitely make a backup of your local workspace (i.e. your developer desktop) because TFS will move things around there too (based on your TFS workspace mapping), but overall TFS was pretty smart about things.

One manual step I had to do after changing the folder structure was to overlay the subfolders and files on my local machine that TFS did not know about that got left behind (e.g. some local projects and files that I did not check in).  This was easy to do, and I’m glad TFS had the intelligence to leave the folder if it wasn’t empty after moving everything it did know about.

Branching was very easy as well.  Just right-click on the server-side folder and select Branch from the context menu.  I chose to branch from the latest version, but the other options like branching from a label or date are useful too.

Now for the really good part… I had to make a couple of small coding changes (bug fixes) on the trunk that also needed to get to the newly created branch.  With my previous source control system, I would have checked the .cs files out in both places, made the changes in one set of files, and then copied and pasted to the other files, and then checked everything back in.

TFS provides a much better solution with its merge capability, and even let me merge based on a changeset so I didn’t have to specify all the files (it knew from the changeset).

Anyway, just thought I would share these TFS successes.  It really is a big help for managing source control and team projects.  My next step will be to build our projects on a dedicated build machine that gets everything from TFS (instead of doing builds locally).

Create a free website or blog at WordPress.com.