Существуют ли существенные улучшения производительности при использовании встроенных классов .NET? - PullRequest
5 голосов
/ 21 июля 2011

Быстрый маленький вопрос ...

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

Так что .NET платформа делает это? Оптимизирована ли реализация Microsoft библиотеки базовых классов каким-либо образом, который я не могу надеяться сопоставить в управляемом коде?

Как насчет чего-то вроде использования KeyValuePair в качестве структуры кортежа с безопасным типом вместо написания моей собственной?

Ответы [ 6 ]

6 голосов
/ 21 июля 2011

Насколько я знаю, .NET Framework не был скомпилирован таким образом, чтобы создавать зацепки для некоторого недоступного в противном случае аппаратного ускорения или чего-то подобного, поэтому для простых вещей, таких как KeyValuePair и Tuple, вам Вы, вероятно, в безопасности, катаясь самостоятельно.

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

  1. Они уже написаны, так зачем выкладываться?
  2. Microsoft провела свой код через довольно строгий процесс проверки, поэтому есть большая вероятность, что их код будет более правильным и более эффективным, чем ваш.
  3. Другие разработчики, которым нужно взглянуть на ваш код, будут точно знать, чего ожидать, когда увидят, что используются стандартные классы фреймворка, в то время как ваши домашние вещи могут на некоторое время заставить их почесать голову.

Обновление

@ Горди также отмечает, что стандартные каркасные классы используются всеми и их собаками, поэтому прирост производительности будет незначительным просто из-за того, что:

  1. класс, скорее всего, не нужно будет статически создавать или создавать точно в срок для вашего кода,
  2. инструкции класса, скорее всего, уже загружены в кеш, так как они, вероятно, недавно использовались другими частями кода. Используя их, вам, скорее всего, не понадобится загружать код в кеш в первую очередь, и вы с меньшей вероятностью выбрасываете другой код из кеша, который, скорее всего, скоро снова будет использоваться.
2 голосов
/ 21 июля 2011

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

1 голос
/ 21 июля 2011

Я предлагаю вам использовать встроенные классы большую часть времени, ЕСЛИ ВЫ ИЗМЕРЕНЫ, ЭТО НЕ БЫСТРО.

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

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

0 голосов
/ 21 июля 2011

Основные причины производительности всегда лежат в архитектуре или сложных алгоритмах, язык не имеет значения.

Библиотека базовых классов Miscrosoft всегда сопровождается сложным объяснением «тяжелых» методов. Таким образом, вы можете легко решить использовать его или найти другой «более быстрый» алгоритм для реализации или использования.

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

0 голосов
/ 21 июля 2011

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

Тогда возникает вопрос о изобретении колеса.У тебя действительно должна быть веская причина для этого.

0 голосов
/ 21 июля 2011

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

И .NET 4.0 уже имеет хорошую Tuple<> реализацию.Хотя в предыдущих версиях .NET вам пришлось бы кататься самостоятельно, если вам нужно что-то большее, чем KeyValuePair.

...