Операторы array и так работают хорошо.



Posted by Аркадий Водяник on August 16, 1999 at 11:38:49:

In Reply to: Re: O том, как бы хорошо работали операторы array. posted by Владимир Секретев, Клуб Любителей Бухгалтерского Учета on August 16, 1999 at 08:29:40:

Отвечаю по методу LIFO:


Теперь по поводу столь большой разницы в статистических результатах,
полученных мною и Аркадием.
Существенная разница между нашими экспериментами заключается в том,
что Аркадий производил замеры в ФК, а я - в ОФ. Может, это повлияло?

Нет, Володя, и ты и я проводили опыты в ОФ (T.Е ФОРМАХ, А НЕ Ф.K).
Перед публикацией этого сообщения мы разговаривали по телефону.
Спасибо за обнаруженную ошибку: директива "%-" в самом деле не обнуляет
счетчики Профилера в формах и first.rpt.

Не по делу, но без обид: не приемлю твое "Профайлер": у нас Лиза - там Лайза,
у нас Микрософт - там Майкрософт и т.д.


Так что же должен делать array? Всего только присваивать нулевому элементу
массива значение 0. При извлечении элемента массива производится сравнение
запрашиваемого индекса со значением, хранящемся в нулевом элементе массива.
В том случае, если индекс оказывается больше, возвращается 0. При этом даже
поиск элемента массива выполнять нет никакой необходимости. Наверно это
будет работать очень быстро.

Спорный вопрос. Все это затеяно, главным образом, для освобождения памяти, а
не для просто обнуления.


Я сознательно не привел своих практических данных о работе этих операторов,
желая ознакомиться сперва с теорией "из первых рук", чтобы утвердиться в том,
что мои соображения верны. Теория - ясна, а вот "чистые" примеры, приведенные
Аркадием не показательны, так как работать-то приходится с реальными базами.

Ну, это уже совсем как у врачей - Аркадий сделал опыты in vitro.
А Володя - in vivo!

Далее:


Вpеменной пpофиль фоpмы SYS0001
~ ~.0001 * Обороты по проводкам
~ ~.0002 * Очистка параметров %
~ ~.0003 i = 0
~ ~.0004 *#План
~ ~.0005 * n1 = [n1 #]; [set %, 'OD'+n1, 0]; [set %, 'OK'+n1, 0]; [set %, 'BA'+n1, 0]
~ ~.0006 *#
################### 98.2% 774.0007 array %
.......

А откуда известно, Володя, что до этого делалось с [set %...] до этого?
Строка 0007. Сколько ей, бедной, пришлось блоков освободить?


Есть подозрение, что причина заключается в том, что array % обходит ВСE дерево индексов
экстрапараметров, а не только свое.

Какое уж тут подозрениe. Так оно и есть. Я же сказал, что выбрал способ 2
в своем сообщении 1505.

Цитирую далее:


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

Здесь есть крупица золота. Это, может, и Суперспособ 4. О некоторых трудностях
этого подхода - в моем следующем сообщении на эту тему.

Еще один профиль. Ну прямо опять in vivo:

                                         .....
~ ~.2901 :F_BUX_P
~ 4.2902 P = PW
~ ~.2903 i = 0
### 16.6% 1526.2904 array D, K, S инициализиуем массив поводок
.....

Володя, откуда я знаю, что было до этого ?!
Нужны дополнительные данные: сколько, что, как?

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

За золотo спасибо. Но будет еще aнализ.
А чистоту экспериментов надо все же повышать.

С уважением,
Аркадий.

P.S. Ускорение операторов array % примерно в 2 раза было достигнуто
в течение прошедшего дня - за счет исключения New на каждом уровне
рекурсии при обходе дерева индексов. Спасибо за полезное влияние.



Пpишедшие ответы: