Russian Qt Forum

Такая разница наводит на мысли о том, что я где-то накосячил.

SQL
CREATE TABLE testTable(field1 INTEGER PRIMARY KEY,field2 INTEGER)
 

Автор сравнивает мягкое с теплым и удивляется ;D
С чего prepare, addBindValue, exec будет отрабатывать за сравнимое время c оператором [] QMap'a?

PRAGMA synchronous;
PRAGMA synchronous = 0 | OFF | 1 | NORMAL | 2 | FULL;

Query or change the setting of the "synchronous" flag. The first (query) form will return the synchronous setting as an integer. When synchronous is FULL (2), the SQLite database engine will use the xSync method of the VFS to ensure that all content is safely written to the disk surface prior to continuing. This ensures that an operating system crash or power failure will not corrupt the database. FULL synchronous is very safe, but it is also slower. When synchronous is NORMAL (1), the SQLite database engine will still sync at the most critical moments, but less often than in FULL mode. There is a very small (though non-zero) chance that a power failure at just the wrong time could corrupt the database in NORMAL mode. But in practice, you are more likely to suffer a catastrophic disk failure or some other unrecoverable hardware fault. With synchronous OFF (0), SQLite continues without syncing as soon as it has handed data off to the operating system. If the application running SQLite crashes, the data will be safe, but the database might become corrupted if the operating system crashes or the computer loses power before that data has been written to the disk surface. On the other hand, some operations are as much as 50 or more times faster with synchronous OFF.

In WAL mode when synchronous is NORMAL (1), the WAL file is synchronized before each checkpoint and the database file is synchronized after each completed checkpoint and the WAL file header is synchronized when a WAL file begins to be reused after a checkpoint, but no sync operations occur during most transactions. With synchronous=FULL in WAL mode, an additional sync operation of the WAL file happens after each transaction commit. The extra WAL sync following each transaction help ensure that transactions are durable across a power loss, but they do not aid in preserving consistency. If durability is not a concern, then synchronous=NORMAL is normally all one needs in WAL mode.

The default setting is synchronous=FULL.

See also the fullfsync and checkpoint_fullfsync pragmas.

PRAGMA synchronous;

Теперь по сути: Вы хотите занести данные в ... куда угодно, но не в БД - конечно это быстрее, потому как при внесении данных в БД создаются ключи

Время вставки в B-tree (в СУБД ведь его используют?), не должно существенно отличаться от времени вставки в balanced tree используемом во всяких там (q)map. По крайней мере, пока все нужные данные болтаются в кеше, а он у SQLite большой (подкурить руками пробовал, не помогает). Время выгрузки данных на диск тоже не должно существенно различаться. Объемы то те же самые. Вот если движок SQL при каждом INSERT гоняет парсер, тады ой. Но я непойму, зачем тогда prepare придуман.

И да, убирать PRIMARY KEY пробовал. Через каждые тысячу вставок начинать новую транзакцию пробовал. Все равно тормозит. Видимо, придется смотреть в сторону NoSQL решений.

The QMap class is a template class that provides a skip-list-based dictionary.

C++ (Qt)
QSqlDriver::hasFeature(QSqlDriver::PreparedQueries)
 

C++ (Qt)
QSqlDriver::BatchOperations
QSqlDriver::Transactions
 

QMap не является деревом.

prepare скорее всего не поддерживается в SQLite, его поддерживают СУБД типа Oracle.