.Net Memory Management Issue : Objects Stuck in Generation 2

I have profiled my App w/ VS2010 profiler, with object lifetime collection enabled.

I was heavilly surprised to see that most instances of a particular struct named "Record" are collected by the GC as Gen 2 instances. I am very upset, as instances of "Record" struct should live less than 500ms each (theoretically).

These structs are simple time series data of 6xInt32 or so, that are read on the flow, Queued/Dequeued in a Queue having a size of 1000, passed to a processor that fires some logic depending on those few millions "Records" sequentially. I do not need to keep more than 50 records at a time.

So my question is : Why could these object live long enough to mainly end up as Second Generation references, and what could I do to ensure they REALLY get dumped off after each computation.

EDIT : I am asking this because I have noticed a drastic performance dropdown for bigger sample sizes (i.e Records Numbers) : if N take T minutes, 2N takes 2,5T minutes or so, and so on.

So there is obviously a leak somewhere.

EDIT 2 : My Bad : Creating a struct instance cannot cause a garbage collection I've changed it to classes and did not notice any significant improvement so far. I'll run the profiler again with classes this time not structs) and see what it gives

EDIT 3 : Many answers suspect Boxing/Unboxing to take place somewhere. I DO use typed generic collections and typed Queues. And "Records" are never attached to any class as members. They are individually handled by events. The ex-Struct (Now Class) implemented an interface and was casted by it when called (this is rather common usage) and I dropped off that interface. No improvement.

EDIT 4 : I have run again the profiler, replacing struct by class. I have the same results :

most instances of CLASS "Record" still end up being collected as Gen2 instances

EDIT 5 : Producers of the Record classes are many parallel BackGroundWorkers (Byte Readers), and there is one Consumer Thread that dispatches the Records to other methods after performing a few checks. Besides I use Events and Delegates to communicate between the different parts.开发者_Go百科 I do not unregister those events because they are useful all along the process (I may be wrong on that point)

If you stored them just as local variables (which may or may not be possible depending on your scenario) they will never end up on the heap at all.

If that's possible, I recommend trying that. You might get a more in depth response, if you post a code sample.

As a sanity check, are you forgetting to unregister static events, or using some other class that may be doing this (some classes fix this via Dispose)?

Also have you looked into the possibility of using the Flyweight pattern?

Edit- Since you now say you are doing something with events, this is highly likely to be a cause of your issues. Are you forgetting to unregister the events?

If you are "heavy" on memory use, and you are using C# 4.0, you could try the "server" GC. Merge your app.config (or web.config) with:

<configuration>
  <runtime>
    <gcServer enabled="true"/>
  </runtime>
</configuration>

(with merge I mean that if you already have some of these sections, use them, otherwhise create them. "configuration" is the first level element of the app.config). This is better for some apps (apps that don't need heavy interaction with the user)

They end up as Second Generation because the GC just decided not to garbage collect them. I don't think it is really a problem to worry about. If you really wanted to you could just reuse the 1000 objects instead of continuously creating new ones. This would make it so that these objects wouldn't need to get garbage collected. You could force Garbage collection to ensure the objects "REALLY" get dumped but that would degrade performance as GC is an expensive operation or so I am told.