Ускорение C#

В Java все переменные, которые вы объявляете, на самом деле являются «ссылками» на объекты (или примитивы), а не самими объектами.

При попытке выполнить один метод объекта , ссылка просит живой объект выполнить этот метод. Но если ссылка ссылается на NULL (ничего, нуль, void, nada), то нет способа, которым метод будет выполнен. Тогда runtime сообщит вам об этом, выбросив исключение NullPointerException.

Ваша ссылка «указывает» на нуль, таким образом, «Null -> Pointer».

Объект живет в памяти виртуальной машины пространство и единственный способ доступа к нему - использовать ссылки this. Возьмем этот пример:

public class Some {
    private int id;
    public int getId(){
        return this.id;
    }
    public setId( int newId ) {
        this.id = newId;
    }
}

И в другом месте вашего кода:

Some reference = new Some();    // Point to a new object of type Some()
Some otherReference = null;     // Initiallly this points to NULL

reference.setId( 1 );           // Execute setId method, now private var id is 1

System.out.println( reference.getId() ); // Prints 1 to the console

otherReference = reference      // Now they both point to the only object.

reference = null;               // "reference" now point to null.

// But "otherReference" still point to the "real" object so this print 1 too...
System.out.println( otherReference.getId() );

// Guess what will happen
System.out.println( reference.getId() ); // :S Throws NullPointerException because "reference" is pointing to NULL remember...

Это важно знать - когда больше нет ссылок на объект (в пример выше, когда reference и otherReference оба указывают на null), тогда объект «недоступен». Мы не можем работать с ним, поэтому этот объект готов к сбору мусора, и в какой-то момент VM освободит память, используемую этим объектом, и выделит другую.

20
задан Community 23 May 2017 в 12:26
поделиться

17 ответов

Кэширование объектов, которые следуют из запроса:

private Item _myResult;
public Item Result
{
     get
     {
          if (_myResult == null)
          {
               _myResult = Database.DoQueryForResult();
          }
          return _myResult;
     }
}

основная техника, которая часто пропускается начинающими программистами и одним из САМЫХ ЛЕГКИХ способов улучшить производительность в приложении.

Ответ портировал от вопроса, которым управляли простофиля этого.

0
ответ дан 29 November 2019 в 22:54
поделиться

Первое, что пришло на ум:

  • Замена неуниверсальные варианты контейнерных классов их универсальными дубликатами
  • Сокращенный упаковка/распаковывание. А именно, используйте дженерики, где возможный и обычно стараются не передавать типы значения как object.
  • Для диалоговых окон с помощью многих динамических средств управления: приостановите рисунок до окончания вставки всех средств управления при помощи SuspendLayout / ResumeLayout. Это помогает особенно при использовании контейнеров макетов.
18
ответ дан 29 November 2019 в 22:54
поделиться

Я имею следующую статью MSDN, отмеченную, и нахожу, что это хорошая общая информация.

Улучшающееся приложение pefformance

.NET
0
ответ дан 29 November 2019 в 22:54
поделиться

Для Windows Forms на XP и Vista: Включите двойную буферизацию через плату. Это действительно вызывает проблемы прозрачности, таким образом, Вы определенно хотели бы протестировать UI:

protected override System.Windows.Forms.CreateParams CreateParams { 
    get { 
        CreateParams cp = base.CreateParams; 
        cp.ExStyle = cp.ExStyle | 0x2000000; 
        return cp; 
    } 
} 
-1
ответ дан 29 November 2019 в 22:54
поделиться

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

я настоятельно рекомендую использование кода профильный инструмент, такой как Профилировщик МУРАВЬЕВ RedGate. Я нашел, что после делания стандартных шагов для оптимизации, что использование Профилировщика я могу далее оптимизировать свой код путем быстрой идентификации области (областей) кода, которые наиболее в большой степени поражены приложением.

0
ответ дан 29 November 2019 в 22:54
поделиться

Это верно для любого языка, не только C#

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

  2. Для новых приложений, проблема состоит в том, как программистам преподают. Им преподают делать из мухи слона. После оптимизации нескольких приложений с помощью это , Вы будете знакомы с проблемой того, что я называю "быстрой общностью" - слой на слой "абстракции", вместо того, чтобы просто спросить, чего требует проблема. Лучшее, на которое можно надеяться, должно работать вперед за ними, говоря им, чем проблемы производительности состоят в том, что они только что вставили, таким образом, они могут вынуть их, как они продвигаются.

0
ответ дан 29 November 2019 в 22:54
поделиться

Не используйте для большого отражения.

0
ответ дан 29 November 2019 в 22:54
поделиться

Используйте Ngen.exe (Должен прибыть поставленный с Visual Studio.)

http://msdn.microsoft.com/en-us/library/6t9t5wcf (По сравнению с 80) .aspx

Собственный Генератор Изображения (Ngen.exe) является инструментом, который улучшает производительность управляемых приложений. Ngen.exe создает собственные изображения, которые являются файлами, содержащими, скомпилировал определенный для процессора машинный код и устанавливает их в собственный кэш изображений на локальном компьютере. Время выполнения может использовать собственные изображения от кэша вместо этого с помощью своевременного (JIT) компилятора для компиляции исходного блока.

0
ответ дан 29 November 2019 в 22:54
поделиться

Я рекомендую Вам те книги:

Эффективный C#.

Более эффективный C#

0
ответ дан 29 November 2019 в 22:54
поделиться

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

2
ответ дан 29 November 2019 в 22:54
поделиться

Используйте состав вместо наследования, предельной упаковки/распаковывания, используйте универсальные наборы, используйте циклы foreach вместо для {} со счетчиком и высвободите средства со стандартом, Располагают шаблон.

Они покрыты подробно в превосходной книге Эффективный C#.

3
ответ дан 29 November 2019 в 22:54
поделиться

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

3
ответ дан 29 November 2019 в 22:54
поделиться
  • Использование StringBuilder, а не большая конкатенация строк. Строковые объекты являются атомарными, и любой , модификация (добавление, к-верхнему, дополнение, и т.д.) на самом деле генерирует абсолютно новый строковый объект вместо того, чтобы изменить оригинал. Каждая новая строка должна быть выделена и в конечном счете собрала "мусор".

  • обобщение А предшествующего оператора: Попытайтесь снова использовать объекты вместо того, чтобы создать партии и многие из них. Выделение и сборку "мусора" может быть легко сделать, но они поражают Вашу производительность.

  • убедиться пользоваться обеспеченными библиотеками Microsoft для большинства вещей. Классы, обеспеченные Платформой часто, используют функции, которые являются недоступными или трудными к доступу из Вашего собственного кода C# (т.е. создание обращается к собственному Windows API). Встроенные библиотеки не всегда самое эффективное, но как правило.

  • Пишущие асинхронные приложения никогда не было легче. Изучите вещи как класс BackgroundWorker.

  • Попытка не определить Структуры, если Вам действительно не нужны они. Переменные экземпляра класса каждый содержит ссылку на фактический экземпляр, в то время как переменные экземпляра структуры каждый содержит отдельную копию.

3
ответ дан 29 November 2019 в 22:54
поделиться

Используйте достойного качественного профилировщика и определите, где Ваши узкие места.

Затем начинают спрашивать, как улучшить производительность.

Любой, кто делает любые общие операторы как, 'избегает отражения', не понимая и Ваш профиль производительности и Вашу проблемную область, должен быть застрелен (или по крайней мере перевоспитан). И, учитывая размер среды .NET в значительной степени бессмысленно говорить об оптимизации C#: мы говорим о WinForms, ASP.NET, BizTalk, Рабочем процессе, SQL-CLR? Без контекста даже общие руководящие принципы могут быть в лучшем случае пустой тратой времени.

Рассматривают также, под чем Вы подразумеваете, 'убыстряются, это' и 'улучшает производительность'. Вы имеете в виду большую эффективность ресурса или понижаете воспринятое время ожидания для конечного пользователя (предполагающий, что существует один)? Это совсем другие проблемы для решения.

, Учитывая форум я чувствую себя обязанным указать что там некоторое довольно хорошее покрытие по этим темам в Завершенном Коде. Не C# определенный ум. Но это - хорошая вещь. Примите во внимание, что определенные для языка микрооптимизации могли бы хорошо быть включены в категорию в следующую версию любого компилятора, который Вы используете, И если различием между для и foreach является грандиозное предприятие Вам, Вы, вероятно, пишете C++ так или иначе, правильно?

[мне понравился Профилировщик МУРАВЬЕВ RedGate, но я думаю, что это могло быть улучшено]

С тем путь, некоторые мысли:

  • тип Использования (SomeType) в предпочтении к экземпляру. GetType (), когда возможный
  • Использование foreach в предпочтении к для
  • Стараются не упаковывать
  • До (я думаю) 3 строки нормально делать StringA + StringB + StringC. После этого необходимо использовать StringBuilder
9
ответ дан 29 November 2019 в 22:54
поделиться

К сожалению, относительно немного оптимизаций являются конкретным языком. Основы применяются через языки:

  • Измеряют уровень против реалистических загрузок
  • , ясно определили цели вести Вас
  • Использование, хороший профилировщик
  • Оптимизирует архитектуру/дизайн относительно рано
  • , Только микрооптимизируют, когда у Вас есть доказанная проблема

, Когда Вы абсолютно доказали, что необходимо микрооптимизировать, профилировщик склонен делать это очевидным, что искать - вещи как предотвращение упаковки и виртуальных вызовов.

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

РЕДАКТИРОВАНИЕ: другое предложение ответов с помощью дженериков и StringBuilder и т.д., конечно, корректно. Я (вероятно, неправильно) предположил, что те оптимизации были слишком "очевидны" ;)

13
ответ дан 29 November 2019 в 22:54
поделиться

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

[еще 112] информация на MSDN в случае необходимости.

10
ответ дан 29 November 2019 в 22:54
поделиться

NGEN помогут с некоторым кодом, но не полагаются на него.

Лично, если Ваш дизайн плох/медленный, нет очень, можно сделать.

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

0
ответ дан 29 November 2019 в 22:54
поделиться
Другие вопросы по тегам:

Похожие вопросы: