Прогнал программу через транзакцию SAT и получил такой результат


Не очень понимаю почему вызов одного и того же ФМ-а занимает разное время и так сильно отличается. Количество вызовов ФМ-ов одинаковое. Сами вызовы тоже идентичны


Может кто подскажет в чем тут дело? Погрешности подсчета?

Вы посмотрите на места вызовов этого ФМ. Скорее всего ФМ вызывается с разными параметрами. Параметры задают условия с которыми работает ФМ. Вполне возможно, что в одном случае условия таковы, что выполняется большой и сложный алгоритм, а в другом - может быть просто выход сразу. И даже может быть такая же работа при одних и тех же параметрах. Самый простой пример: кэшированное чтение. При первом вызове с набором параметров идет чтение из БД (медленно), а при втором - уже чтение из кэша.
И даже при чтении из БД тоже такое может быть, т.к. может происходить кэширование на уровне самой БД.

Кодер, нет вызовы ИДЕНТИЧНЫ. Т.е. параметры различаются конечно, но в обоих случаях поведение идентично - первый вызов читает из БД, все последующие из кеша. Собственно сам ФМ как раз и написан для кешированного чтения.

Ну так вы же сами все и объяснили: первое чтение из бд , второе - из кэша. Вот и разница. Кто из них тормозит - смотрите сами внимательно ( т.к. если кэш сделали\используете плохо, то тупить будет он, а не бд).

Имеется ввиду первое чтение при аналогичных параметрах.

Но в общем нашел я ошибку. Как оказалось (как всегда) сам стормозил. Я из БД читаю данные, потом их сортирую по нужному полю. Только вот при чтении из внутренней таблицы я забыл указать BINARY SEARCH.
В одном случае всего 2 тыс записей и отсутствие BIUNARY SEARCH особо не влияет. А в другом случае 90 тыс. записей, поэтому и получается такой перекос в работе

всем спасибо за участие - не забывайте про BINARY SEARCH!

Если таблица будет использоваться преимущественно для многократного чтения без операций модицификации, желательно использовать sorted или hash, для избежания таких вот проблем.