Огромная разница в производительности между объединением sqlite 3.7 и 3.16
У меня есть исполняемый файл MS Window, написанный на неуправляемом простом "C", который помещает оболочку GUI вокруг встроенного ядра базы данных (SQLite). Возможность SQLite обеспечивается пакетом объединения 3.7.14.1 В частности, 2 файла sqlite3.h и sqlite3.c Единственное изменение, которое я делаю в файлах "из коробки", - это добавление строки: #define SQLITE_ENABLE_COLUMN_METADATA 1
Все это скомпилировано в Win 7(64-битной) системе с использованием Visual Studio 2008, НО я компилирую его как 32-битное приложение.
Я поменял местами файлы sqlite3.h и sqlite3.c для файлов из пакета слияния 3.15.2 Опять-таки, ЕДИНСТВЕННОЕ изменение заключается в добавлении строки: #define SQLITE_ENABLE_COLUMN_METADATA 1
Я не делаю никаких изменений в конфигурации моего проекта. Я только меняю 2 файла!
У меня есть сложный сценарий, который загружает в память большую БД ~ 600 Мбайт, а затем выполняет много операций SELECTS и передает результаты в Excel (используя функциональность моей оболочки GUI).
Моя проблема. Производительность версии с использованием пакета объединения 3.7.14.1 более чем в сто раз быстрее, чем пакета объединения 3.15.2. Я использую точно такой же "скрипт".
Я попробовал объединить пакет 3.16, и это не лучше. Я могу видеть, что потеря производительности происходит в механизме SQL (путем отображения всплывающих окон при входе и выходе из машины SQL. С точки зрения моей оболочки GUI, конфигурации Visual Studio, конфигурации проекта все вещи одинаковы. Я предполагаю производительность Проблема заключается в некоторых ключах компилятора в пакетах объединения.
Кто-нибудь знает, где я должен начать искать?
0 ответов
Проблема, вероятно, вызвана планировщиком запросов следующего поколения SQLite, который был представлен в версии 3.8.0. Как только вы найдете конкретные медленные запросы, вы можете попробовать запустить их с префиксом explain. Это сбросит план запроса, что позволит вам увидеть разницу в планах, созданных в 3.7.14 и 3.15.2.
Трудно точно сказать, в чем проблема, не просматривая запрос или базу данных, но часто производительность запросов можно улучшить с помощью индексов, поэтому я сначала поищу в плане сканирование таблиц, которых можно было бы избежать, добавив индексы. Еще одна вещь, которую стоит попробовать, - это запустить analyze в вашей базе данных для создания таблиц статистики, которые помогут планировщику построить оптимальные планы запросов.