В SQLite подготовленные операторы действительно улучшают производительность?
Я верю тому, что Вы надеетесь делать, "Изменяют размеры/Передискретизируют" Ваших изображений. Вот хороший сайт, который дает инструкции и обеспечивает служебный класс (Что я также, оказывается, использую):
http://www.codeproject.com/KB/GDI-plus/imgresizoutperfgdiplus.aspx
2 ответа
Подготовленные операторы повышают производительность за счет кэширования плана выполнения для запроса после того, как оптимизатор запросов нашел лучший план.
Если запрос у вас нет сложного плана (например, простого выбора / вставки без соединений), тогда подготовленные операторы не дадут вам большого улучшения, поскольку оптимизатор быстро найдет лучший план.
Однако, если вы выполнили тот же тест с запросом, в котором было несколько объединений и использовались некоторые индексы, вы увидите разницу в производительности, поскольку оптимизатор не будет запускаться каждый раз при выполнении запроса.
Да - это имеет огромную разницу в том, используете ли вы sqlite3_exec () или sqlite3_prepare_v2 () / sqlite3_bind_xxx () / sqlite3_step ( ) для массовых вставок.
sqlite3_exec () - это только удобный метод. Внутри он просто вызывает ту же последовательность sqlite3_prepare_v2 () и sqlite3_step () . Ваш примерный код вызывает многократно sqlite3_exec () в буквальной строке:
for(int i=0;i<recs;i++){
sql = @"INSERT INTO test (id,field1,field2,field3,field4,field5,field6,field7,field8,field9,field10) VALUES (%d,1,2,3,4,5,6,7,8,9,10)";
sqlite3_exec(dbConn, [sql UTF8String],NULL,NULL,NULL);
}
Я не знаю внутренней работы синтаксического анализатора SQLite, но, возможно, синтаксический анализатор достаточно умен, чтобы распознать это вы используете одну и ту же буквальную строку, а затем пропускаете повторный анализ / повторную компиляцию с каждой итерацией.
Если вы попробуете тот же эксперимент с изменяющимися значениями, вы увидите гораздо большую разницу в производительности.