title: List<T>.AddRange implementation suboptimal
body: <p>Profiling my C# application indicated that significant time is spent in <code>List&lt;T&gt;.AddRange</code>. Using Reflector to look at the code in this method indicated that it calls <code>List&lt;T&gt;.InsertRange</code> which is implemented as such:</p>
  
  <pre><code>public void InsertRange(int index, IEnumerable&lt;T&gt; collection)
  {
      if (collection == null)
      {
          ThrowHelper.ThrowArgumentNullException(ExceptionArgument.collection);
      }
      if (index &gt; this._size)
      {
          ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument.index, ExceptionResource.ArgumentOutOfRange_Index);
      }
      ICollection&lt;T&gt; is2 = collection as ICollection&lt;T&gt;;
      if (is2 != null)
      {
          int count = is2.Count;
          if (count &gt; 0)
          {
              this.EnsureCapacity(this._size + count);
              if (index &lt; this._size)
              {
                  Array.Copy(this._items, index, this._items, index + count, this._size - index);
              }
              if (this == is2)
              {
                  Array.Copy(this._items, 0, this._items, index, index);
                  Array.Copy(this._items, (int) (index + count), this._items, (int) (index * 2), (int) (this._size - index));
              }
              else
              {
                  T[] array = new T[count];          // (*)
                  is2.CopyTo(array, 0);              // (*)
                  array.CopyTo(this._items, index);  // (*)
              }
              this._size += count;
          }
      }
      else
      {
          using (IEnumerator&lt;T&gt; enumerator = collection.GetEnumerator())
          {
              while (enumerator.MoveNext())
              {
                  this.Insert(index++, enumerator.Current);
              }
          }
      }
      this._version++;
  }
  
  private T[] _items;
  </code></pre>
  
  <p>One can argue that the simplicity of the interface (only having one overload of InsertRange) justifies the performance overhead of runtime type cheching and casting.
  But what could be the reason behind the 3 lines I have indicated with <code>(*)</code> ?
  I think it could be rewritten to the faster alternative:</p>
  
  <pre><code>is2.CopyTo(this._items, index);
  </code></pre>
  
  <p>Do you see any reason for not using this simpler and apparently faster alternative?</p>
  
  <p><strong>Edit:</strong></p>
  
  <p>Thanks for the answers. So consensus opinion is that this is a protective measure against the input collection implementing the CopyTo in a defective/malicious manner. To me it seems like a overkill to constantly pay the price of 1) runtime type checking 2) dynamic allocation of the temporary array 3) double the copy operation, when all this could have been saved by defining 2 or a few more overloads of InsertRange, one getting <code>IEnumerable</code> as now, the second getting a <code>List&lt;T&gt;</code>, third getting <code>T[]</code>. The later two could have been implemented to run around twice as fast as in the current case.</p>
  
  <p><strong>Edit 2:</strong></p>
  
  <p>I did implement a class FastList, identical to List, except that it also provides an overload of AddRange which takes a T[] argument. This overload does not need the dynamic type verification, and double-copying of elements. I did profile this FastList.AddRange against List.AddRange by adding 4-byte arrays 1000 times to a list which was initially emtpy. My implementation beats the speed of standard List.AddRange with a factor of 9 (nine!). List.AddRange takes about 5% of runtime in one of the important usage scenarios of our application, replacing List with a class providing a faster AddRange could improve application runtime by 4%.</p>