Это такая проблема - "Выделить участки кода с проблемной производительностью"? Выделили - и решили проблему?

Как найти медленный код, изолировать причины и устранить их - написано тонны руководств. И понятно, что на выходе - код, работающий быстрее.

Какую пользу бизнесу принесут потраченные на Вашу разметку человеко-часы? Какую проблему бизнеса это решит?

Tzimie Apr 5 at 14:07

По правилу 90/10 или 80/20 максимальных эффект от оптимизации небольшого объема кода. С помощью этого подхода вы и сможете выделать эти куски.

alterzorro Apr 6 at 10:24

Вы не понимаете мой вопрос или Вам нечего ответить, потому что не существует такой проблемы?

Tzimie Apr 6 at 10:43

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

alterzorro Apr 6 at 10:49

Простите, а сейчас Вы на какой вопрос отвечали? Напомню мой вопрос: какую именно проблему бизнеса вы решали своей раскраской? Прямой вопрос априори требует прямого ответа.
Если вы упорно хотите продолжать говорить о погоде - ну, ваше право.

Tzimie Apr 6 at 12:30

Я уже ответил много раз. Нахождение места в процедуре, которое следует оптимизировать в первую очередь. Что здесь непонятного?

Tzimie Apr 6 at 13:31

А если уровнем выше, время выполнения этой процедуры критично для бизнеса. Но думаю это и так очевидно, иначе бы оптимизацией этой процедуры никто бы не занимался

alterzorro Apr 5 at 13:21

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

Tzimie Apr 5 at 14:08

Да, такие процедуры плохо, но увы, это жизненный пример.