Много ли старых предупреждений о ColdFusion Performance все еще применяются в CFMX 8?

Question

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

Применяется ли что-либо из этого в ColdFusion MX 8? Они действительно так сильно влияют на производительность?

• Используйте compare() или compareNoCase() вместо is not при сравнении строк
• Не используйте evaluate(), если нет другого способа написания кода
• Не использовать iif()
• Всегда используйте struct.key или struct[key] вместо structFind(struct,key)
• Не использовать incrementValue()

Answer 1

Я согласен с мыслями Томалака о преждевременной оптимизации. Сравнение не так читабельно, как «экв.»

Как говорится, в Центре разработчиков Adobe есть отличная статья о производительности ColdFusion: http://www.adobe.com/devnet/coldfusion/articles/coldfusion_performance.html

Answer 2

Coldfusion MX 8 в несколько раз быстрее, чем MX 7 со всех учетных записей. Когда это вышло, я прочитал много мнений, что простое обновление для повышения производительности без изменения строки кода стоило того ... Оно того стоило. Прибавляя вычислительную мощность и доступность памяти, вы, как правило, можете сделать гораздо больше с менее оптимизированным кодом.

Значит ли это, что мы должны перестать заботиться и писать что угодно? Нет. Скорее всего, там, где мы выберем наибольшее количество ярлыков, нам придется больше развивать систему там.

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

Для меня я стараюсь основывать это на:

• сколько будет использовано,
• насколько это будет дорого для моей ожидаемой базы пользователей,
• насколько это важно / центрально для всего,
• как часто я могу возвращаться к коду, чтобы распространить его на другие области

Чем больше эти типы идей лежат в «вероятно, так или иначе, я буду», я обращаю больше внимания на это. Если он должен быть читабельным, а производительность - небольшим, это лучший способ обеспечить устойчивость кода.

В противном случае, я позволяю предметам бороться за мое внимание, пока я решаю и строю вещи, имеющие реальную (э) ценность.

Единственное самое большое одолжение, которое мы можем сделать сами, - это использовать фреймворк с любым проектом, независимо от его размера, и делать мелкие вещи с самого начала.

Таким образом, нет смысла бояться возвращаться к работе в системе, которая изначально предназначалась для временного взлома, но никогда не подверглась повторному анализу.

Answer 3

• Compare() / CompareNoCase(): сравнение без учета регистра также дороже в Java. Я бы сказал, что это все еще верно.
• Не используйте evaluate(): Абсолютно - если нет другого пути. В большинстве случаев это так.
• Не используйте Iif(): Я не могу много сказать об этом. В любом случае, я им не пользуюсь, потому что все, что идет в комплекте с 1016, - это отстой.
• struct.key over StructFind(struct,key): Я подозреваю, что внутренне оба используют один и тот же метод Java для получения элемента структуры. StructFind() - это просто еще один вызов функции в стеке. Я никогда не использовал его, так как понятия не имею, какую пользу это принесет. Я думаю, что это только для обратной совместимости.
• IncrementValue(): я никогда этим не пользовался. Я имею в виду, что это 16 символов и даже не увеличивает переменную на месте. Который был бы единственным оправданием его существования.

Некоторые проблемы попадают в угол "преждевременной оптимизации", ИМХО. Помимо личных предпочтений или стиля кодирования, я бы только начал заботиться о некоторых тонкостях в тяжелом внутреннем цикле, который застревает в приложении.

Например, если вам не нужно сравнение строк без учета регистра, бессмысленно использовать CompareNoCase(). Но я бы сказал, что в 99,9% случаев разница в производительности незначительна. Конечно, вы можете написать цикл, который умножит 100000 итераций различных операций, и вы обнаружите, что они выполняют по-разному. Но в реальных ситуациях эти академические различия редко оказывают какое-либо ощутимое влияние.