Добавил на форму еще 2 закладки (Set(Types::Record), InventTable.setTmp()), соответственно выкладываю обновленные результаты сравнения:
Цель изменения - сравнить производительность уже подготовленных курсоров со стандартным MultiSelect
Цитата:
2 слойная Аксапта
Кол-во записей - 97000
Set(Types::String)
выделение всех записей - 7 Мб
передача - 10 Мб пиковое выделение - 190 сек
Set(Types::Record)
выделение всех записей - 125 Мб
передача - 75 Мб пиковое выделение - 9 сек
TmpTable (винчестер 4200 оборотов)
выделение всех записей - 17 Мб + большая загрузка винчестера (чтение + запись)
передача - 2 Мб пиковое выделение - 715 сек + большая загрузка винта (чтение)
TmpTable (using Join)
выделение всех записей - 17 Мб + большая загрузка винчестера (чтение + запись)
передача - 2 Мб пиковое выделение - 203 сек - !!почти не загружен винчестер
InventTable.setTmp()
выделение всех записей - 52 Мб + средняя загрузка винчестера (чтение + запись) - долго по времени.
передача - 2 Мб пиковое выделение - 55 сек + средняя загрузка винчестера (чтение)
Standard MultiSelect
обработка - 184 Мб пиковое выделение - 65 сек
Видим существенное приемущество Set(Record). В то же время памяти он, ессно, кушает больше всего.
------------------------
Также провел небольшое сравнение на 3-уровневой (записей - 941) - тонкий клиент.
По совету Сергея установил плохой канал (2000 байт- bandwidth, 700 - задержка, что соответствует среднему dial-up соединению).
Все результаты ожидаемые.
Методы, которые передают на сервер только перечень номенклатур, а не целые записи, практически не создают клиент-серверного трафика.
Кстати - в такой конфигурации InventTable.setTmp() скушал много, и обращений к серверу было 941 - по кол-ву записей. И выполнялось все это довольно долго.
Через Set(Types::String) и TmpTable все было довольно быстро и без большой нагрузки на канал.
А standardMultiSelect вообще долго выполнялся (800 секунд), при этом очень большой трафик от сервера (при этом 945 вызовов с сервера).