asp.net и производительность

Question

Q:

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

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

Теперь я хочу узнать несколько советов («делай» и «не делай») относительно проблем с производительностью в asp.net и в Интернете в целом. Буду признателен, если есть какой-нибудь пример по поводу этой идеи.

например: мне сказали, что:

int count = dataTable.Rows.Count;
for(int i = 0 ; i<count ; i++)
{
   //Do some thing
} 

более производительный, чем:

for(int i = 0 ; i<dataTable.Rows.Count ; i++)
{
   //Do some thing
} 

Answer 1

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

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

Нельзя изменить скорость света (задержка), но вы можете написать эффективный запрос данных, который обращается только к необходимым данным, используя соответствующую индексацию и, возможно, денормализацию.Да, и N + 1 - это важная вещь.

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

В «сети в целом»;кеширование, сжатие (транспорт и контент - например, минимизация js / css), домены без файлов cookie для статического контента (возможно, CDN), фермы серверов, жирные каналы и соответствующие процессоры ...

Answer 2

Первая версия может быть более производительной, поскольку вы не переоцениваете dataTable.Rows.Count на каждой итерации цикла.

Если каждый вызов dataTable.Rows.Count стоит дорого (и потенциально может быть)первая версия действительно будет лучше.

---

Что касается общих советов по производительности:

• Всегда принимайте решение , что для вас означает производительность (задержка?пропускная способность? что-то еще?)
• Всегда выясняйте, как вы его измеряете.
• Выясните, когда ваш код работает достаточно (когда вы закончите).
• Профилируйте свой код, чтобы найти худшие точки производительности.
• Исправьте их и перепрофилируйте.