Изучение проблем производительности так же неизбежно, как и освоение отладки. Даже если вы в точности и совершенстве понимаете затраты на исполнение вашего кода, он будет взаимодействовать с другим программным обеспечением, над которым у вас нет будет такого контроля или понимания. Как бы то ни было, на практике проблемы производительности немного отличаются и проще, чем отладка в целом.
Предположим, что вы или ваши клиенты считают систему или одну из подсистем слишком медленной. Перед тем, как вы попытаетесь ускорить ее, вам стоит построить ее мысленную модель и определить, почему она медленная. Вы можете использовать профилировщик или хороший лог, чтобы определить, где именно затрачивается время или иной ресурс системы. Существует известное утверждение, что 90% времени затрачивается на 10% кода. Я бы добавил к этому важность затрат на чтение и запись в оценке проблем производительности. Часто большая часть времени тратится либо на чтение информации, либо на ее запись. Хорошим первым шагом в построении мысленной модели проблемы будет нахождение затратных операций чтения и записи и 10% кода, занимающих большую часть ресурса.
Существует множество измерений в производительности компьютерной системы и множество потребляемых ресурсов. Первое, что стоит измерить, это реальное время на исполнение программы. Логирование этого времени особенно полезно тем, что оно может указать на непредвиденные обстоятельства, которые возникают в ситуациях, когда использовать профилировщик непрактично. Однако, этот параметр не всегда дает полную картину происходящего. Иногда вычисления, которые требуют чуть больше общего времени, но занимают меньше процессорного времени, покажут себя лучше в реальном окружении. Аналогично, память, пропускная способность сети, доступ к базе данных или другому серверу могут оказаться, в конечном счете, гораздо дороже, чем процессорное время.
Загруженность общих ресурсов, которые синхронизированы между собой, может привести к взаимной блокировке и ресурсному голоду. Взаимная блокировка - это невозможность продолжить исполнение программы из-за недостаточной синхронизации запрашиваемых ресурсов. Ресурсный голод - это невозможность правильно запланировать работу компонента. Если это можно предусмотреть, то лучше всего с самого старта проекта иметь способ измерения загруженности ресурсов. Даже если загруженности не будет, очень полезно иметь возможность утверждать это с уверенностью.
Следующее: Как устранять проблемы производительности