Субоптимальная реализация <T>.AddRange списка

Профилирование моего приложения C# указало то значительное время, потрачен в List<T>.AddRange. Используя Отражатель для рассмотрения кода в этом методе указал, что он звонит List<T>.InsertRange который реализован как таковой:

public void InsertRange(int index, IEnumerable<T> collection)
{
    if (collection == null)
    {
        ThrowHelper.ThrowArgumentNullException(ExceptionArgument.collection);
    }
    if (index > this._size)
    {
        ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument.index, ExceptionResource.ArgumentOutOfRange_Index);
    }
    ICollection<T> is2 = collection as ICollection<T>;
    if (is2 != null)
    {
        int count = is2.Count;
        if (count > 0)
        {
            this.EnsureCapacity(this._size + count);
            if (index < 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<T> enumerator = collection.GetEnumerator())
        {
            while (enumerator.MoveNext())
            {
                this.Insert(index++, enumerator.Current);
            }
        }
    }
    this._version++;
}

private T[] _items;

Можно утверждать, что простота интерфейса (только наличие одной перегрузки InsertRange) выравнивает по ширине производительность наверху типа выполнения cheching и кастинга. Но что могло быть причиной позади этих 3 строк, я указал с (*) ? Я думаю, что это могло быть переписано к более быстрой альтернативе:

is2.CopyTo(this._items, index);

Вы видите, что какие-либо основания для того, чтобы не использовать эту более простую и по-видимому более быструю альтернативу?

Править:

Спасибо за ответы. Таким образом, мнение о согласии - то, что это - защитная мера против входного набора, реализовывая CopyTo дефектным/злонамеренным способом. Мне на излишество походит постоянно платить, цена 1) типа выполнения, проверяющего 2) динамическое выделение временного массива 3), удваивают операцию копии, когда все это, возможно, было сохранено путем определения 2 или еще несколько перегрузок InsertRange, одно получение IEnumerable как теперь, второе получение a List<T>, третье получение T[]. Более поздние два, возможно, были реализованы для обтекания дважды с такой скоростью, как в текущем случае.

Редактирование 2:

Я действительно реализовывал класс FastList, идентичный Списку, за исключением того, что он также обеспечивает перегрузку AddRange, который берет T [] аргумент. Для этой перегрузки не нужны динамическая проверка типа и двойное копирование элементов. Я действительно представлял этот FastList. AddRange против Списка. AddRange путем добавления 4 массивов байтов 1000 раз к списку, который был первоначально emtpy. Моя реализация бьет скорость стандартного Списка. AddRange с фактором 9 (девять!). Список. AddRange берет приблизительно 5% времени выполнения в одном из важных сценариев использования нашего приложения, заменение Списка с классом, обеспечивающим более быстрому AddRange, могло улучшить время выполнения приложения на 4%.