Итак, mythz не понравился мой не совсем научный вопрос о тестировании в предыдущем вопросе SO, но, поскольку я хотел бы переключиться на OrmLite, мне нужно выяснить, если он медленный, и если да, то почему.
В своем «исследовании» я пришел к выводу, что сложные объекты, которые в OrmLite помечены как JSON, являются виновниками очень медленных SELECT.
Поэтому я создал новый проект, который фокусируется исключительно на OrmLite и не сравнивается ни с чем, кроме себя самого, и цель здесь состоит в том, чтобы увидеть различия между пометкой объектов JSON и отсутствием их.
Его можно найти на GitHub:
https://github.com/tedekeroth/ormlitebenchmarking
Решение выглядит так:
Я использую OrmLite 5.1.1 на Windows 7, 2,6 ГГц, 24 ГБ ОЗУ и нет
Загрузка процессора в настоящее время, используя MySql 5.6. Приложение подключается к
127.0.0.1 (root / root) и нуждается в базе данных "ormlite".
Я включил ThrowOnError:
OrmLiteConfig.ThrowOnError = JsConfig.ThrowOnError = true;
Приложение выглядит так:
- Нет данных: только созданный объект, никакие свойства не имеют данных
- Примитивы: заполнены только некоторые простые примитивные свойства
- Prim + один комплекс: все примитивы, как указано выше + один объект blobbed комплекс
- Полные данные: все вышеперечисленное + еще 2 сложных объекта blobbed
Кнопка Создать сначала создает 10 000 объектов в списке, а затем они сохраняются с помощью метода вставки OrmLite. Измерение времени выполняется только для вставок, а не для создания объектов.
public void AddRow<T>(T coreObject) where T : CoreObject
{
long id = 0;
using (var _db = _dbFactory.Open())
{
id = _db.Insert<T>(coreObject, selectIdentity: true);
}
}
Кнопка Read считывает все строки в таблице и воссоздает объекты Customer:
public List<T> FetchAll<T>()
{
using (var _db = _dbFactory.Open())
{
List<T> list = _db.Select<T>();
return list;
}
}
Итак, тестирование должно быть сделано так:
- Выберите режим и нажмите Создать , отобразится время, необходимое
- Нажмите Чтение , чтобы прочитать все строки, которые в данный момент находятся в таблице
Чтобы проверить другой режим, очистите таблицу БД (customer), чтобы она была чистой.
СРАВНИТЕЛЬНЫЙ
ВСТАВИТЬ
Создание 10 000 объектов (не измерено) и вставка их в базу данных.
- Нет данных: ~ 26-27 секунд
- Примитивы: ~ 27,1-27,4 секунды
- Прим + один комплекс: ~ 27,5-29 секунд
- Полные данные: ~ 28 секунд
Итак, в целом, примерно одинаково, 26-29 секунд.
SELECT
Чтение 10 000 объектов из базы данных, как указано выше.
- Нет данных: ~ 460 мс
- Примитивы: ~ 700-720 мс
- прим + один комплекс: ~ 970-1030 мс
- Полные данные: 30000-32000 мс (30-32 секунд)
Выводы
«Полные данные» - это, очевидно, место, где появляется большой привкус.
Сложные объекты большого размера, которые добавляются (ContactDetails), похоже, запутали это. Я заметил это в предыдущем тесте, но сам объект не очень сложен, см. Ниже. Поэтому я не уверен, почему он так прыгает или эти цифры разумны.
Вот почему я подумал, что, возможно, Mythz может взглянуть на этот более чистый тест? =)
Вопрос заключается в следующем: почему сохранение объекта (в JSON согласно OrmLite) замедляет SELECT таким образом?
[Serializable]
public class ContactDetails
{
public List<ContactItem> ContactItemList
{
get; set;
}
public ContactItem CurrentContactItem
{
get; set;
}
public ContactItem DefaultContactItem
{
get; set;
}
public bool IgnorePrimaryWaitBuffer
{
get; set;
}
public ContactDetails(List<ContactItem> contactItemList, ContactItem currentContactItem, ContactItem defaultContactItem)
{
ContactItemList = contactItemList;
CurrentContactItem = currentContactItem;
DefaultContactItem = defaultContactItem;
}
public ContactDetails()
{
}
}