Сравнительный тест Производительности SQLite — почему: память: так замедлите … только 1.5X с такой скоростью, как диск?
Ветвь Git является указателем на коммит. Когда вы объединяете две ветви (фактически вы объединяете две фиксации), создается новая фиксация, и текущая ветка перемещается в новую фиксацию. Объединенная ветвь не меняется.
Вот пример.
Текущая ветвь - A, и есть другая ветвь B, которая в прошлом отличалась от A.
HEAD -> A -> o o <- B
| |
o o
| /
o o
| /
o
|
После git merge B создается новый коммит (у него два родителя, потому что это коммит слияния), и ветвь A перемещается, чтобы указать на вновь созданный коммит. B сохраняет свою прежнюю позицию.
HEAD -> A -> o
| \
o o <- B
| |
o o
| /
o o
| /
o
|
После git merge B, git diff B отображает изменения, которые находятся в ветви A, но отсутствуют в ветви B. Это изменения, выполняемые в левой ветви графа, в коммитах, которые недоступны из коммита B.
HEAD -> A -> o
| \
/-> o o <- B
in A | | |
but not |-> o o
in B | | /
\-> o o
| /
o
|
6 ответов
Это связано с тем, что SQLite имеет кеш страниц. Согласно Документации , кэш страниц по умолчанию составляет 2000 1 КБ страниц или около 2 МБ. Поскольку это около 75-90% ваших данных, неудивительно, что эти два числа очень похожи. Я предполагаю, что в дополнение к кешу страниц SQLite, остальные данные все еще находятся в кеше диска ОС. Если у вас есть SQLite для очистки кэша страниц (и дискового кэша), вы увидите некоторые действительно существенные различия.
Вы делаете SELECT, вы используете кэш памяти. Попробуйте чередовать SELECT с UPDATE.
Может ли быть так, что sqlite3 фактически не записывает ваши данные на диск из кеша? что может объяснить, почему цифры похожи.
Также возможно, что ваша ОС выполняет пейджинг из-за недостатка памяти?
Хочу заметить, что вы сосредоточены на запросах, которые требуют относительно больших наборов данных для возврата. Интересно, какой эффект вы бы увидели с меньшими наборами данных? Чтобы возвращать одну строку много раз, может потребоваться много искать диск - время произвольного доступа к памяти может быть намного быстрее.
База данных памяти в SQLite на самом деле является кешем страниц, который никогда не касается диска. Поэтому вы должны забыть об использовании памяти db в SQLite для настройки производительности
Можно отключить журнал, отключить режим синхронизации, установить кэш больших страниц, и вы будете иметь почти одинаковую производительность в большинстве операций, но долговечность будет потеряна.
Из вашего кода совершенно ясно, что вы ДОЛЖНЫ ПОЛЬЗОВАТЬСЯ параметрами команды и ТОЛЬКО BIND, потому что это убрало более 90% вашей тестовой производительности.
Мой вопрос к вам: что вы пытаетесь протестировать?
Как уже упоминалось, база данных SQLite: memory: DB такая же, как дисковая, то есть выгружаемая, и единственная разница в том, что страницы никогда не записываются на диск. Таким образом, единственная разница между ними заключается в том, что запись на диск: в память: не требуется (также не требуется выполнять какие-либо операции чтения с диска, когда страница диска должна быть выгружена из кеша)
. Но чтение / запись из кеша может составлять лишь часть времени обработки запроса, в зависимости от запроса. В вашем запросе есть предложение where с двумя большими наборами идентификаторов, членами которых должны быть выбранные строки, что дорого.
Как демонстрирует Кэри Миллсап в своем блоге по оптимизации Oracle (вот типичное сообщение: http: // carymillsap.blogspot. com / 2009/06 / profiling-with-my-boy.html ), вам необходимо понимать, какие части обработки запроса требуют времени. Предполагая, что набор тестов членства представляет 90% времени запроса, а дисковый ввод-вывод 10%, переход к: memory: сохраняет только эти 10%. Это крайний пример, вряд ли репрезентативный, но я надеюсь, что он показывает, что ваш конкретный запрос искажает результаты. Используйте более простой запрос, и количество операций ввода-вывода в обработке запроса увеличится, и, следовательно, выгода от: memory:.
В заключение, мы экспериментировали с виртуальными таблицами SQLite, где вы отвечаете за фактическое хранилище, а также используя контейнеры C ++, которые типизированы в отличие от способа хранения значений ячеек в SQLite, мы могли увидеть значительное улучшение времени обработки по сравнению с: memory :, но это немного уходит в тему;) --DD
PS: поэтому я здесь комментирую :), чтобы сказать, что последняя версия SQLite не использует 1 КБ страницы по умолчанию в Windows: http://www.sqlite.org/changes.html#version_3_6_12