Фильтры и итоги в бровзе раза в 4 замедлились 🙁
Отвечаю сразу по двум письмам на данную тему (второе от Владимира Смелика).
Замедление — закономерный результат.
И дело даже не в том, что изменился размер самого поля. Все дело — в принципиально разной обработке полей типа LONG и STRING. Если для обработки полей типа LONG компилятор генерит обычный машинный код с простыми ASM-операторами, то даже для простейших операций с переменными типа STRING используется специальный внутренний стек. Например, для выполнения оператора Clip(STR) генерится (упрощенно) следующий код:
- «затолкнуть» (Push) переменную STR в стек 2 ASM-команды + вызов стековой функции
- выполнить операцию CLIP() над содержимым вершины стека один вызов стековой функции
- «вытолкнуть» (Pop) результат из стека в переменную STR 2 ASM-команды + вызов стековой функции А для операции сравнения двух операндов, одним из которых является строка, генерится (без применения CLIP() или UPPER()):
- PushToStack(STR)
- PushToStack(STR1)
- CompareStack()
А если, не дай бог, вторым операндом будет не строка, а, например, то-же LONG, то генерится:
- PushToStack(STR)
- Преобразование строки на вершине стека в тип DECIMAL
- Преобразование LONG в тип DECIMAL и заталкивание его в стек
- Сравнение двух DECIMAL`ов на стеке
Кстати, исходя из вышеописанного видно, что следует избегать кода типа:
if STR = 1 ...
лучше уж писать
if STR = '1' ...
И, заметьте, все это совершенно не зависит от длинны строки. Так что в этом плане скорости обработки строк различной длинны практически одинаковы. Теперь, надеюсь, понятно, почему фильтр по LONG намного быстрее чем аналогичный фильтр по STRING.
Что-же касается итогов, то здесь возможны два случая:
- используется выражение-фильтр для View
- используется рукописная вставка с операторами сравнения.
В первом случае замена LONG на STRING приведет ТОЛЬКО к замедлению отработки самого VIEW. Сам же цикл подсчета итогов от такой замены не замедлится (если, конечно, длина записи не очень сильно увеличится). Во втором случае получим ощутимое замедление как самого процесса обновления страниц, так и процесса подсчета итогов.
Поэтому, отвечая на вопрос В.Смелика, скажу, что замена LONG на STRING практически не должна повлиять на скорость отработки операторов NEXT()/PREVIOUS(). Опять же замечу — при условии, что длинна самой записи увеличится не очень сильно.
Что же касается самого использования итогов в бровзах, то полностью согласен с Владимиром — да, конечно, наглядно! да, возможно, удобно для юзера! Но — тормозно, сташно!!! Особенно, как правильно заметил Владимир, при работе в сети. Так что, если у тебя не SQL-база, то лучше убрать итоги из бровзов и, при необходимости, сделать отдельную процедурку подсчета всевозможных итогов в виде обычного отчета. Ну а для SQL-баз заменить шаблонный способ подсчета итогов
или на обычный суммирующий SQL-запрос или использовать хранимые процедуры на SQL-сервере.