Viv,

(1) So maybe a more representative test would be to create the List within the loop.

Not really in my scenario - It's a property of the class and used as long as the object is alive

(2)>Interesting. Roughly at what point would Queue become preferable ?

(a) one element at a time

If it's just adding/Enqueuing the list is faster (tested upto 1024000 items)

When you start Dequeuing (list : x = list[0]; list.RemovAt(0) ) the Queue is the faster

(b) whole arrays - tested with arrays of int[1024]
For the list, I use an extension method AddArray (below)
Adding - the list always wins

Add + DeQueue [ for List : CopyTo + RemoveRange ]

As long as the total size of the list/queue is less than 105 * 1024 int = the list wins
After that the queue is the faster

Think I'll stop performance measuring for a while - the forrest and the trees

Made a class with enqueue/dequeue array stuff - it has a list. I tested with ToBase64 and FromBase64
The queue - about 16 secs
The list : about 45 secs

Much to my surprise until I saw that CanTransformMultipleBlocks of both Tobase64Transform and FromBase64Transform is false. They also have small inputblock sizes

So the killer is Dequeueing from the list in small blocks ( 1 byte or 3 bytes)


Conclusion :
For adding elements or whole arrays - a list is always faster

For Dequeue operations the list is winning if you can dequeue big arrays at a time ( CopyTo + RemoveRange) [ and total size of the list somewhere less than 105 * 1024 * 4 bytes ]




I'll have that Shnaps now ...

Cheers,

		public static void AddArray<T>(this List<T> list, T[] array)
		{
			if (array.Length <= Tuning.AddRangeMinimumItems) // 128
			{
				foreach (T item in array)
					list.Add(item);
			}
			else
			{
				list.AddRange(array);
			}
		}

>Hi,
>
>
>>>Don't know why the speed difference but have you tried pre-setting the capacity of list using the Capacity property (in both scenarios)?
>>>Best,
>>>Viv
>>
>>Just did, Viv
>>
>>There is no difference, and I would not have expected one since there are 6000000 iterations and the list must be expanded to its capacity after the first iteration
>
>True. So maybe a more representative test would be to create the List within the loop.I tried this:

int nTimes = 600000;
>        int Size = 10000;
>
>        private void UseWithCapacity()
>        {
>            int[] buf = new int[Size];
>
>            for (int i = nTimes; --i != 0; )
>            {
>                List<int> list = new List<int>();
>                list.Capacity = Size;      //With: 1:32 Without: 1:52
>                foreach (int item in buf)
>                    list.Add(item);
>            }
>        }

and, as annotated, there was some improvement, tho not huge, when the capacity was pre-defined. When using AddRange() setting the Capacity in this way gave no discernable benifit....
>
>
>>
>>
>>I was quite surprised to find that out
>>
>>[Context]
>>I'm playing with streams, subclassed the stream to implement a base64 encoder/decoder
>>
>>The problem with ToBase64Transform and FromBase64Transform is that you have to buffer the input, transform (pieces of )the input [ you do not know in advance whether to call TransformBlock or TransformFinalBlock ], and put the transformations on an outputbuffer
>>
>>

>>protected Queue<Byte> InBuffer = new Queue<byte>();
>>protected Queue<Byte> OutBuffer = new Queue<byte>();
>>

>>
>>The Read and Write of the stream work with arrays
>>
>>So I tried - just for fun - how it would perform if I were to use List(byte)
>>
>>I started testing with different array sizes - and found out that the List() is actually quite fast compared to the Queue
>>
>>[ and the list is slower with many items compared to the queue ]
>
>Interesting. Roughly at what point would Queue become preferable ?
>Regards,
>Viv