If you, like me, have a background in C programming it's a spine
reaction to avoid lots of memory allocations. So when you
encounter a situation in managed code where you need to allocate
lots of objects over time it feels natural to introduce a pool
of objects. However I remembered reading somewhere that the .Net
garbage collector is optimized for short lived objects so I
started looking into this a little more.  Back to your C
background; if you had to create lots of small objects on the
fly in C you would either have a pool of objects or create your
own memory management. Turns out that .Net essentially creates
that custom memory management for you. Hence memory allocation
is not so bad in .Net. At least not for objects that are not
extremely large (since they are handled in a different way). The
Garbage collector is also optimized for short lived objects. So
I had to write a test.  My first test used a ConcurrentQueue
into which I placed two test objects. I then started two threads
that would take one obj