Когда оптимизация действительно стоит времени, проведенного на нем?

YAGNI. Если только люди не жалуются, много.

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

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

Я думаю, что это правильный подход.

Оптимизация того стоит, когда это необходимо.

Если мы пообещали время отклика клиента в поисках пакета праздничных пакетов, которые находятся на 5 секунд или меньше, и что система будет работать на одном сервере Oracle (каких-либо спецификаций), и поиски принимают 30 секунд при пиковой нагрузке, то Оптимизация определенно стоит того, потому что мы не собираемся платить иначе.

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

Хорошая публикация всех.

Вы смотрели на ненужное использование транзакций для простого выбора (ов)? Я сгорел на этом несколько раз ... Я также сделал какой-то очистку кода и обнаружил, что многие графики возвращаются, возможно, 10 записей необходимы ... ВКЛ. Вкл. ... Иногда это не ваш код сами по себе, но кто-то резка Углы .... Удачи!

Если клиент не видел необходимость выполнять оптимизацию производительности, то нет причин для этого нет.

Определение измеримых требований к производительности SLA с клиентом (т. Е. 95% запросов завершены в течение 2 секунд) рядом с началом проекта позволяет вам знать, если вы встречаете эту цель или если У вас больше оптимизации. Тестирование производительности в текущих и предполагаемых будущих нагрузках дает вам данные, которые вам нужно увидеть, если вы встречаетесь с SLA.

Использовать закон Амдаля . Он показывает, что является общим улучшением при оптимизации определенной части системы.

Также: Если он не сломан, не исправляйте его.

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

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

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

Обычно думать, что способ найти этот код , измеряя время, проведенное функциями , но на мой разум, который обеспечивает только подсказки - вам все еще нужно воспроизводить детектив. Что касается меня прямо к коду Stackshots . Вот пример 40-кратных ускорений, достигнутых, найдя и фиксируя несколько проблем. Другие на так сообщили о ускорении факторов от 7 до 60, достигнутые с небольшим усилием. *

* (7x: Комментарий 1 . 60x: Комментарий 30 .)

Частично достичь (1-уровня наследования) можно с помощью дженериков:

class PropertyBase<T>
{
    public static Type GetMyType() { return typeof (T); }
}

// the base class is actually a generic specialized by the derived class type
class ConcreteProperty : PropertyBase<ConcreteProperty> { /* more code here */ }

// t == typeof(ConcreteProperty)
var t = ConcreteProperty.GetMyType();

Бит подкласса не будет работать, поскольку статический метод привязан к типу. Это метод типа , а не метод экземпляра. Подтип не содержит статических методов базового типа, поскольку они являются различными типами и статический метод привязан к базовому типу. Даже если компилятор может позволить вызывать статический метод базового класса как через производный класс, он в действительности вызовет метод из базового класса. Это просто сахар из синтаксиса. По этой же причине невозможно «переопределить» статические методы в подклассах, поскольку это не имеет смысла.

Как все говорили в других ответах на вопросы, когда есть денежный смысл изменить что-то, то он нуждается в изменении. В большинстве случаев достаточно хорошо выигрывает день. Если клиенты не жалуются, то это достаточно хорошо. Если они жалуются, то исправьте это достаточно, чтобы они перестали жаловаться. Гибкие методологии дадут вам некоторые рекомендации о том, как знать, когда достаточно. Кого волнует, если что-то использует на 40% ЦП больше, чем вам кажется, это нужно, если это работает и клиенты довольны, то это достаточно хорошо. Действительно просто, получить его работает и ремонтопригоден, а затем ждать жалоб, которые, вероятно, никогда не придет.

Если бы то, что вас беспокоит, действительно было проблемой, НИКТО бы никогда не начал использовать Java для создания критически важных серверных приложений. Или Python, или Erlang, или что-то еще, что не является C в этом вопросе. И если бы они сделали это, ничего не было бы сделано в сроки, чтобы даже приобрести тот первый клиент, который вы так беспокоитесь о проигрыше. Вы будете знать заранее, что вы должны изменить что-то хорошо, прежде чем это станет проблемой.