C# статические функции работают лучше, чем нестатические функции вне уменьшенного использования памяти?
Я принимаю это public или private static цели, должно быть, уменьшили использование памяти, вследствие того, что существует только одна копия статической цели в памяти.
Это походит, потому что метод является статическим, который мог бы сделать метод потенциальной точкой для дальнейшей оптимизации компилятором CLR вне того, что возможно с нестатической функцией. Просто неосновательная теория, хотя, таким образом, я приехал для выяснения у Вас всех.
Сделать static public или private методы обеспечивают какой-либо увеличенный выигрыш в производительности вне уменьшенного использования памяти?
(Примечание: я не интересуюсь ответами, которые говорят на проблемах преждевременной оптимизации. Конечно, это - разумный совет, которому я каждый день следую, но это не означает, что оптимизация время от времени не необходима. (дважды отрицательный!). Позвольте мне потворствовать своему любопытству, самое меньшее),
5 ответов
Из Статические классы и члены статических классов (Руководство по программированию на C #)
Вызов статического метода генерирует инструкцию вызова на промежуточном языке Microsoft (MSIL), тогда как вызов метода экземпляра генерирует инструкцию callvirt, которая также проверяет наличие ссылок на нулевой объект. Однако в большинстве случаев {{1} }} разница в производительности между двумя несущественна.
Помимо того, что сказал наблюдатель, ваш вопрос предполагает неправильное понимание того, что делают методы экземпляра. Независимо от того, является ли функция статической или нет, в памяти имеется только одна копия кода функции. Нестатический метод должен вызываться через объект, но объект не несет собственной частной копии метода.Таким образом, использование памяти статическими и нестатическими методами фактически идентично, и, как отмечали другие, характеристики производительности почти идентичны.
Нестатические переменные-члены , однако, существуют отдельно для каждого создаваемого вами объекта. Но почти всегда бесполезно беспокоиться об использовании памяти, если только у вас в программе нет проблем с памятью.
Учитывая размер базы данных, можно легко перестраивать индексы один раз в месяц. Но по мере увеличения размера, скажем, около 500 ГБ, вы можете делать это дважды в месяц.
-121--1452826-Консервы... Вряд ли. Учитывая ваш пример - простое использование временного значения bool, я предполагаю, что у вас есть что-то слабое в виду: -) Вы можете реализовать какую-то структуру Stack:
1) Push old value to stack
2) Load new value
3) Do Stuff
4) Pop from stack и заменить использованное значение.
Rough (AKA Untested) Пример (Не удается найти синтаксис стека прямо сейчас)
bool CurrentValue = true;
Stack<bool> Storage= new Stack<bool>
Storage.Push(CurrentValue);
CurrentValue=false;
DoStuff();
CurrentValue = Storage.Pop();
//Continue
Хорошие ответы - в основном это не имеет значения, что является ответом почти на каждый вопрос такого рода. Даже если это и имело значение - Если время выполнения вашей программы стоило доллара, то этот вид проблемы, скорее всего, будет стоить несколько центов, и очень вероятно , что есть и другие вещи , которые стоят намного больше .
Это немного не по теме, но тем не менее важно.
Выбор метода статического или экземпляра не должен основываться на времени выполнения (что в любом случае не имеет значения). Это должно быть основано на том, работает ли метод с объектом. Например, все методы Math. * Статичны, а, например, (большинство) методов String. * являются экземплярами, поскольку они работают с экземпляром String. Моя личная философия: хороший дизайн должен компенсировать несколько циклов, которые можно сохранить где-то еще .
Другой взгляд на эту тему: я недавно работал с парнем, которому сказали, что статические методы - зло, потому что они возвращают нас в темный век процедурного программирования, и поэтому их следует избегать любой ценой. Это привело к появлению странных примеров классов, которым требовались экземпляры для доступа к методам, которые не интересовались внутренним устройством объекта.
Уф, было приятно получить это из моего сердца.
MeasureIt , чтобы быть уверенным, но вы обнаружите, если не создаете глобальный суперкомпьютер для обработки транзакций сверхмалого объема. кластер, это не будет иметь заметной разницы.