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

профилирование моего приложения c# показало, что значительное время тратится на List<T>.AddRange. Использование Reflector для просмотра кода в этом методе показало, что он вызывает 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) оправдывает накладные расходы на производительность проверки типа времени выполнения и литья. Но что может быть причиной за 3 строками, которые я указал с (*) ? Я думаю, что может переписать на более быструю альтернативу:

is2.CopyTo(this._items, index);

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

Edit:

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

Edit 2:

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