Существует ли связь между статическим анализом кода и производительностью приложения

Question

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

Есть ли какой-либо способ выявить узкие места в производительности на этапе разработки?Дает ли анализ кода какие-либо подсказки относительно производительности?

Answer 1

Все зависит от правил, которые вы запускаете во время анализа кода, но я не думаю, что вы можете предотвратить узкие места в производительности только с помощью CA.

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

Answer 2

Нет, за исключением очень незначительных случаев (например, для Java используйте StringBuilder в цикле, а не string добавляет).

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

Например:изменение bubblesort на quicksort не окажет существенного влияния на ваше приложение, если вы последовательно сортируете списки из полудюжины элементов.Или если вы запускаете сортировку один раз, посреди ночи, и это не задерживает другую обработку.

Answer 3

Если мы говорим .NET, то и да, и нет...FxCop (или встроенный анализ кода) содержит в себе ряд правил, которые касаются проблем производительности.Однако этот список довольно короток и ограничен по своему характеру.

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

Answer 4

Как правило, нет, хотя исходя из опыта Я могу посмотреть на систему, которую никогда раньше не видел, и распознать некоторые подходы к проектированию, которые приводят к проблемам с производительностью:

• Насколько он велик с точки зрения строк кода или количества классов?Это сильно коррелирует с проблемами производительности, вызванными чрезмерным дизайном.

• Сколько существует уровней абстракции?Каждый слой - это шанс потратить больше циклов, чем необходимо, и этот эффект усиливается, особенно если каждая операция воспринимается как "довольно эффективная".

• Существуют ли отдельные структуры данных, которые необходимо согласовывать?Если да, то как это делается?Если есть попытка с помощью уведомлений строго синхронизировать структуры данных, это красный флаг.

• Изменяется ли какая-либо из категорий вводимой в систему информации с низкой частотой?Если это так, то, скорее всего, он должен быть "скомпилирован", а не "интерпретирован".Это может стать огромным выигрышем как в производительности, так и в простоте разработки.

• Общим мотивом является следующий:Программист А создает функции, которые обертывают сложные операции, такие как доступ к базе данных, для сбора большого объема информации.Программист А считает это очень полезным для других программистов и ожидает, что эти функции будут использоваться с определенным уважением, а не случайно.Программист B ценит эти мощные функции и часто использует их, потому что они позволяют так много сделать всего одной строкой кода.(Программисты B и A могут быть одним и тем же человеком.) Вы можете видеть, как это вызывает проблемы с производительностью, особенно если распределено по нескольким уровням.

Это первое, что приходит на ум.