WildSeryVlad F,

Тебе даже конкретный код приводят, где батчсайз по 255 файрдаком режется, нет, всё равно тестишь 256.
Ты что хотел сказать конкретно? Что не нравится? И в чем ценность твоего поста?
Все это я тестировал еще в пятницу, когда мы только обозначили возможные проблемы с контекстами и еще не переходили к коду. Или, я не понял, не нравится на столько подробное исследование?

Симонов Денис,

ОК. Сегодня постараюсь проверить в рабочем порядке.

Симонов Денис,

Вот именно. И я не думаю, что что-то там принципиально изменится.

Симонов ДенисVlad F,

попробуй потестить размер пакетов кратный 255. Я думаю там циферки получше выйдут
Денис, как то так опять получается, что это, как предыдущие ваши смелые предположения, оказалось неверным:
255 -> 02:31
510 -> 01:30
1020 -> 01:10
2040 -> 01:00
8160 -> 00:55

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

Денис! Очень прошу, не надо в тридцать третий раз пускаться в одни и те же объяснения.)) Тем более, что я их не просил. Моя ремарка относилась к педпрложениям, что "больше 256 ставить смысла нет" и "на 255 должны быть улучшения". Все.
Хотя на счет неравноценности по коммитам отчасти согласен.
Вопроса про "обычный препарированный", однако, недопонял. Скармливаю ему одиночный параметризированный запрос. Сам его не препарирую, в надежде на то, что перед первым выполнением он его сам отпрепарирует и так и будет использовать, как описано в хелпе.
Хотя какой там использовать, - он же не его на самом деле использует, а внутренний скрытый блок.

hvladVlad F,

Вы не в церкви, вас не обманут (ц)
При чем здесь не в церкви, причем не обманут? КТО ЗДЕСЬ?!!
На самом деле я очень оправдался в своих ожиданиях.))

Симонов Денис,

Денис, еще не известно, а выыигрывает ли , никто же с одиночным сравнительно не измерял.))) Или измерял?
На самом деле ваш покорный слуга изначально, из общих соображений, предположил, что вроде пачками оно должно быть быстрее. Ну и в любом случае полученные результаты меня более чем устраивают.

Мимопроходящий,

я домеряю, решил уже, в рабочем порядке. Может завтра, работать ведь тоже надо. ))

P.S. Настоящих буйных мало, вот и нету вожаков (c) ))

Vlad FПривожу результаты тестирования института Array DML (FireDAC) для запросов на вставку.
Тестовая рабочая станция: HP Compaq 8200 Elite CMT PC с дополненным до 8 Гб ОЗУ и оценкой производительности 5.1 по шкале Win7.
Windows 7 Prof x64.
FB 3.0.3.329x64 в режиме embedded. В конфиге изменение только в части Providers=Engine12.
Тестовая таблица-пробник: пара полей варчар(10), по одному типа дата и целое и дюжина нумериков(18,4). Вставляется миллион записей параметризированным запросом.
Показатели времени выполнения в зависимости от значений ArraySize (размерности массива пакетной вставки) в мин/сек, с коммитом после каждой пачки:
128 -> 03:21
256 -> 02:23
512 -> 01:26
1 024 -> 01:09
2 048 -> 01:01
4 096 -> 00:59
8 192 -> 00:54
16 384 -> 00:51
32 768 -> 00:50
Очевидно, что дальнейшее увеличение размер пакета не имеет смысла, а дополнительное возможное увеличение производительности лежит в области распараллеливания процесса вставки. В результате чего, вероятно, можно приблизится (и, не исключено, что и превзойти) озвученные kdv выше показатели "миллион за 25 секунд". Ну и резюмируя, хочу отметить, что FireDAC в целом показал себя с FB очень хорошо и при его штатном наличии в современных версиях среды разработки нет никакого смысла продолжать пользоваться IBX.
Итак, момент истины. Привожу результаты тестирования вставки в точности тех же данных посредством FireDAC без использования ArrayDML. Как и в предыдущем эксперименте замеры производились по два раза, бралось лучшее время. В таблице приведены показатели времени вставки в формате мин:сек в зависимости от числа последовательных запросов между промежуточными коммитами:
1 024 -> 01:22
2 048 -> 01:20
4 096 -> 01:22
8 192 -> 01:21
16 384 -> 01:21
32 768 -> 01:20
Из чего можно сделать пару очевидных выводов:
1) от числа последовательных вставок между коммитами ничего не зависит;
2) вставка посредством Array DML (FireDAC) позволяет получить в Firebired почти 40%-тное преимущество ((80-50)/80*100%=37.5%) над вставкой отдельными запросами, несмотря на использование им в этом режиме эмуляции (execute block), вместо институтов Naitive API, как, например в Interbase.