Leonid KudryavtsevYUBAPRAGMA synchronous = OFF...не дает сколь-либо существенного прироста скорости (в моем случае где-то в пределах стат погрешности)...
Теоретически, при synchronous = OFF неоткуда взяться:
YUBAВ смысле быстродействия, как писалось ранее это ничего не дает, и не могло дать, т.к. основное время выполнения запроса занимают дисковые операции .
Т.к. лично я бы ожидал, что при synchronous = OFF дисковые операции должны завершаться мгновенно. Данные передаются в OS и управление тут же возврашается обратно. Собственно ввода-вывода никто ждать не должен.

Теоретически. Конкретный код (и версии), разумеется, может работать как-то неправильно и содержать баги. Вполне возможно, еще какие-то блокировки или миханизмы срабатывают. Нужно запускать конкретный код и как-то смотреть. что происходит.
====
P.S.
Сам использовал SQLite для сохранения десятков миллионов строк данных. Ничего даже не настраивал. Т.к. лично мне производительности вполне хваталоБыло написано другое - Даже то, что совместное применение PRAGMA synchronous = OFF and PRAGMA journal_mode = MEMORY не дает сколь-либо существенного прироста скорости (в моем случае где-то в пределах стат погрешности), . И далее - а по отдельности эффекты применения сопоставимы.. В общем, примерно как в вашей ссылке на тест.
И еще, при передаче 1000 строк (как я), или 5000 строк - время выполнения меняется не пропорционально. Точно не помню, увеличивается примерно в 2 раза, а не в 5 раз. Т.е., производительность растет.
Однако, мне нужно много коротких транзакций, и я тестирую для своих задач.

Leonid KudryavtsevIMHO & AFAIK
Тогда SQLite странный выбор. Лучше взять полноценные БД (PostgreSQL, MySQL, Oracle etc)Нет, это не рацо. БД небольшая по объему, но должна быть быстрой. Повторюсь, передача данных CSV-файлами через RAM-Disk меня вполне бы устроило. Лишний здесь только RAM-Disk. ) И все это по любому должно писаться в БД.
SQLite декларируется именно как замена файловых операций. И убиваются сразу 2 зайца.)

Leonid KudryavtsevТеоретически. можно попытаться создать
https://docs.microsoft.com/en-us/windows/desktop/memory/creating-named-shared-memory
и затолкать файл БД SQLite туда. Если ни журналы, ни транзакции Вам на самом деле не нужны, может даже и заработает.
Не люблю я named pipes.) Сейчас используются Сокеты (вопросы те-же, что и с named pipes).
Вначале нужно придумать протоколы обмена, потом перекодировать в CSV-string, передать, раскодировать, записать в БД в ее формате в несколько таблиц. Кроме того, Сокеты ненадежны в смысле автовосстановления связи после обрыва - надо перезапускать и сервер и клиент. Иначе то восстанавливается, то нет - по наитию.)
С named pipes немного по другому, но тоже радости мало. Сокеты, имхо, поинтересней будут.

Leonid Kudryavtsev, нет, перед begin цикла.
Ради интнреса попробовал писать в БД текстовые строки вида -
insert into foo(a0,a1,a2,a3,a4) values (5.8920000000000000E+03, ..... ,2.4204000000000000E+04 );
через, через snprintf() при аналогичной конфигурации.
Dima TЛучше параметризованный запрос как выше посоветовали. Еще можно сформировать свой инсерт, читай про snprintf() Время исполнения зашкаливает - в 4-5 раз больше худшего, до 390 мс.

Вроде задача решена. Этим:


Удалось добиться быстродействия (4-10) мс/запрос, что соответствует в среднем ~8МБ/с. В режиме :memory: было 2 мс/запрос.
Этого должно вполне хватить для конкретных задач.
Всем спасибо.

Так как тема Sqlite в многопоточной программе была закрыта модератором (и поделом ей)), то сообщаю результаты здесь. Тем более, что тема являлась продолжением этой.
Суть темы была в том, что Sqlite работала в основном потоке, а потоки событий не видели указатель на базу данных.
Было сделано предположение, что объект класса cDB (непосредственно работает с БД) выходил из области видимости основного потока, и потоки событий cDB не видели.
Не знаю, насколько такое предположение правильно, но основной поток был модифицирован таким образом, чтобы класс cDB оставался в области видимости основного потока. После такой модификации все потоки стабильно работают с Sqlite.
Задача решена.