new List or List Pool?

In C#, what is better for performance?

Assuming this is all declared in a class called "MyStaticClass"

     void FunctionThatGetsCalledAlot(...)
     {
		List<SomeClass> previousAttributes = new List<SomeClass>();
		previousAttributes.AddRange(SomeStuff);
		node.RemoveAttributes();
        ....
     }

Or this:

	private class ThreadSafeObjectPool<T> where T : new()
	{
		private readonly Stack<T> pool = new Stack<T>();

		public T Get()
		{
			lock (this.pool)
			{
				if (this.pool.Count > 0)
				{
					return this.pool.Pop();
				}
			}

			return new T();
		}

		public void Return(T v)
		{
			lock (this.pool)
			{
				this.pool.Push(v);
			}
		}
	}

     private static readonly ThreadSafeObjectPool<List<SomeClass>> previousAttributes = new ObjectPool<List<SomeCLass>>();
     void FunctionThatGetsCalledAlot(...)
     {
		List<SomeClass> previousAttributes = MyStaticClass.previousAttributes.Get();

        try
        {
           previousAttributes.Clear();
		   previousAttributes.AddRange(SomeStuff);
           ....
        }
        finally
        {
             MyStaticClass.previousAttributes.Return(previousAttributes);
        }
     }

Instead of using a new List<> every time, we have a kind of 'List Pool', to avoid having to call 'new' every time, and the garbage collector doesn't have to clean it up. In theory, should this be faster or would it lose all of its optimization value because of the call to Clear() every time?

Of course, the answer is:

It Depends

You don't show the type or the size of SomeStuff. Nor do you say whether previousAttributes grows from its initial size during the execution of FunctionThatGetsCalledAlot.

If SomeStuff (just the collection, not its contents (unless they are value type instances)) is over 85 kbytes, then some of this discussion will have to change - objects over 85k are stored in the Large Object Heap (LOH) and follow different rules.

It's important to realize that the .NET Garbage Collector (GC) is a generational GC. It has three generations, Gen0 (for objects that were created since the last collection), Gen1 (for objects that have survived exactly one collection) and Gen2 (for older objects). Gen0 collections are very cheap. So, your simple implementation should not put a lot of stress on the GC - each list will last a short while and will be quickly cleaned up in a Gen0 collection. One of the larger costs will be the zero-ing out of the new list objects every time you create on (but your Clear call probably does a less efficient version of the same work).

One thing you might consider is to create each list so it's the right size to start with:

var previousAttributes = new List<SomeClass>(SomeStuff.Length);  //or Count()

When you create a list and then you make it bigger than its initial size, it resizes the underlying array by allocating a new array and making the old one eligible for GC. By getting the size right (or a little bigger than possibly needed), you get rid of the resize.

Where pools are handy are when you have large objects (those stored in the LOH). For a bunch of reasons, LOH objects really stress the garbage collector (they are only every collected in expensive Gen2 collections, their heap management follows very different rules...). Writing a LOH-capable pool, however, is hard.

All in all, you are very likely better off going with the simple solution. It's the kind of scenario where the GC does a pretty good job.

Most garbage collectors are optimized for live objects, ignoring garbage (unreachable objects).

An example garbage collector splits the heap into two halves, one active and the other inactive, and copies all objects reachable from Main into the inactive half (which then becomes active). If it's 95% garbage, only the 5% real memory takes any work (and allocating merely increments a pointer).

This is wasteful, and garbage collection in real use is more complex and efficient (most active objects also take zero processing each collection), but the point is discarding objects can be thought of as "free" normally.

I'd say in this case, the object initialization (after allocation) would be roughly as expensive as cleaning it up (there will probably be internal objects that are discarded anyway, so you're not avoiding all garbage).