Дженерики C# имеют выигрыш в производительности?

Не только да, но и HECK ДА. Я не верил, как большой из различия они могли сделать. Мы сделали тестирование в VistaDB после перезаписи небольшого процента базового кода, который использовал ArrayLists и HashTables к дженерикам. 250% или больше были улучшением скорости.

Read мой блог о тестировании мы сделали на дженериках по сравнению со слабыми наборами типа. Результаты унесли наш ум.

я начал переписывать много старого кода, который использовал наборы со слабым контролем типов в со строгим контролем типов. Одна из моих самых больших властей с интерфейсом ADO.NET - то, что они не представляют больше способов со строгим контролем типов вложить данные и. Время кастинга от объекта и назад является абсолютным уничтожителем в крупномасштабных приложениях.

Другой побочный эффект сильного ввода состоит в том, что Вы часто будете находить ссылочные проблемы со слабым контролем типов в своем коде. Мы нашли, что до структуры реализации в некоторых случаях, чтобы не оказывать давление на GC мы могли далее ускорить наш код. Объедините это с сильным вводом для Вашего лучшего увеличения скорости.

Иногда необходимо использовать интерфейсы со слабым контролем типов в точечном сетевом времени выполнения. Каждый раз, когда возможный, хотя ищут способы остаться со строгим контролем типов. Это действительно имеет огромное значение в производительности для не тривиальные приложения.

Дженерики в C# являются действительно универсальными типами с точки зрения CLR. Не должно быть никакого принципиального различия между производительностью универсального класса и определенным классом, который делает ту же самую вещь. Это отличается от Дженериков Java, которые являются большим количеством автоматизированного броска типа при необходимости или шаблонов C++, которые расширяются во время компиляции.

Вот хорошая статья, несколько старая, который объясняет базовую конструкцию: "Разработка и реализация Дженериков для Общеязыковой среды выполнения.NET" .

, Если бы Вы пишете от руки классы для определенных возможностей задач, Вы, может оптимизировать некоторые аспекты, где Вам были бы нужны дополнительные обходы через интерфейс универсального типа.

, Таким образом, может быть выигрыш в производительности, но я рекомендовал бы универсальное решение сначала, затем оптимизировал бы в случае необходимости. Это особенно верно, если Вы ожидаете инстанцировать дженерика со многими различными типами.

Я сделал некоторое простое сравнительное тестирование на ArrayList по сравнению с Универсальными Списками для различного вопроса: Дженерики по сравнению со Списками массива , Ваш пробег будет варьироваться, но Универсальный Список был в 4.7 раза быстрее, чем ArrayList.

Так да, упаковывая / распаковывание очень важно при выполнении большого количества операций. Если бы Вы делаете простой материал CRUD, я не волновался бы об этом.

Дженерики являются одним из способа параметризовать код и избежать повторения. При рассмотрении описания программы и мысли о записи отдельного класса для контакта с каждым объектом данных я склонился бы к дженерикам. Наличие единого класса, заботящегося о многих объектах данных, вместо многих классов, которые делают то же самое, увеличивает Вашу производительность. И конечно Ваш уровень, измеренный в способности изменить Ваш код, обычно более важен, чем производительность компьютера.:-)

По данным Microsoft, Дженерики быстрее, чем кастинг (упаковывающий/распаковывающий примитивы) , который является верен . Они также утверждают, что дженерики обеспечивают лучшую производительность, чем кастинг между ссылочными типами, , который, кажется, неверен (никто не может вполне доказать его).

Tony Northrup - соавтор MCTS 70-536: Основа Разработки приложений - указывает в той же книге следующее:

я haven’t, бывший в состоянии для репродуцирования выигрышей в производительности дженериков; однако, по данным Microsoft, дженерики быстрее, чем использование кастинга. На практике кастинг оказался несколько раз быстрее, чем использование дженерика. Однако Вы, вероятно, won’t замечаете различия в производительности в своих приложениях. (Мои тесты более чем 100 000 повторений заняли только несколько секунд.), Таким образом, необходимо все еще использовать дженерики, потому что они безопасны с точки зрения типов.

я не был в состоянии воспроизвести такие выигрыши в производительности с дженериками по сравнению с кастингом между ссылочными типами - таким образом, я сказал бы, что увеличение производительности "предполагается" более, чем "значительное".

при сравнении универсального списка (например), с определенным списком для точно типа, Вы используете тогда различие, минимально, результатами JIT-компилятора является почти то же.

при сравнении универсального списка со списком объектов тогда существуют значительные преимущества для универсального списка - никакая упаковка/распаковывание для типов значения и никакие проверки типа на ссылочные типы.

также классы универсального набора в .net библиотеке были в большой степени оптимизированы, и Вы вряд ли добьетесь большего успеха сами.

Если Вы думаете об универсальном классе, который называет методы в некотором интерфейсе, чтобы сделать его работу, которая будет медленнее, чем определенные классы с помощью известных типов, потому что вызов метода интерфейса медленнее, чем (невиртуальный) вызов функции.

, Конечно, если код не является медленной частью критического по отношению к производительности процесса, необходимо сфокусироваться ясности.

В случае универсальных наборов по сравнению с упаковкой и др., с более старыми наборами как ArrayList, дженерики являются победой производительности. Но в подавляющем большинстве случаев это не самое важное преимущество дженериков. Я думаю, что существует две вещи, которые имеют намного большую выгоду:

1. Безопасность с точки зрения типов.
2. Сам документирующий иначе более читаемый.

Дженерики способствуют безопасности типов, вызывая более гомогенный набор. Предположите спотыкаться через строку, когда Вы будете ожидать интервал Ай.

Универсальные наборы - также больше сам документирование. Рассмотрите эти два набора ниже:

ArrayList listOfNames = new ArrayList();
List<NameType> listOfNames = new List<NameType>();

Чтение первой строки Вы могли бы думать, что listOfNames является списком строк. Неправильно! Это на самом деле хранит объекты типа NameType. Второй пример не только осуществляет это, типом должен быть NameType (или потомок), но код более читаем. Я знаю сразу же, что должен пойти, находят TypeName и изучают, как использовать его только путем рассмотрения кода.

я видел, что многие из них "делают x, выполняют лучше, чем y" вопросы на StackOverflow. Вопрос здесь был очень справедлив, и как оказалось, дженерики являются победой любым путем, Вы свежуете кошку. Но в конце дня точка должна предоставить пользователю что-то полезное. Уверенный Ваше приложение должно быть в состоянии работать, но оно также не должно отказывать, и необходимо быть в состоянии быстро ответить на ошибки и запросы новых функций. Я думаю, что Вы видите, как эти последние две точки соединяются с безопасностью типов и кодируют удобочитаемость универсальных наборов. Если это был противоположный случай, если ArrayList превзошел List< по характеристикам;>, я, вероятно, все еще взял бы List<> реализация, если различие в производительности не было значительным.

, Насколько производительность идет (в целом), я был бы готов держать пари, что Вы найдете большинство своих узких мест производительности в этих областях в течение Вашей карьеры:

1. Плохой дизайн базы данных или запросов базы данных (включая индексацию, и т.д.),
2. Плохое управление памятью (упущение звонить располагают, глубоко стеки, содержа на объекты слишком долго, и т.д.),
3. Неподходящее управление потоком (слишком много потоков, не называя IO на фоновом потоке в настольных приложениях, и т.д.),
4. Плохой дизайн IO.

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

См. Блог Rico Mariani в MSDN также:

http://blogs.msdn.com/ricom/archive/2005/08/26/456879.aspx

Q1: Который быстрее?

версия Дженериков значительно быстрее, посмотрите ниже.

статья немного стара, но предоставляет подробную информацию.

Мало того, что можно покончить с упаковкой, но и универсальными реализациями, несколько быстрее, чем не универсальные дубликаты со ссылочными типами из-за изменения в конкретной реализации.

оригиналы были разработаны с конкретной дополнительной моделью в памяти. Эта модель действительно никогда не использовалась (и будет плохая идея так или иначе), но проектное решение вынудило несколько методов быть виртуальными и таким образом uninlineable (на основе текущих и прошлых оптимизаций JIT в этом отношении).

Это решение было исправлено в более новых классах, но не может быть изменено в более старых без него являющийся потенциальным двоичным изменением повреждения.

, Кроме того, повторение через foreach на List<> (а не IList<>) происходит быстрее из-за Перечислителя ArrayList, требующего выделения "кучи". По общему признанию это действительно приводило к неясная ошибка

Джезы быстрее!

Я также обнаружил, что Tony Northrup написал неправильные вещи о производительности дженериков и нежененых в его книге.

Я написал об этом в моем блоге: http://andriiybuday.blogspot.com/2010/01/generics-performance-vs-non-genericance.html

Вот отличная статья, в которой автор сравнивает производительность дженериков и неремиков:

NAYYERI .net / use-regies-to-улучшается "