Linq To Sql против производительности Entity Framework
Я искал последние тесты производительности, которые сравнивают L2S и EF, и не смог найти ни одного, который тестировал бы вызов хранимых процедур с использованием выпущенной версии EF. Итак, я провел несколько собственных тестов и нашел некоторые интересные результаты.
Правильно ли выглядят эти результаты? Стоит ли тестировать по-другому?
Один экземпляр контекста, один вызов sproc: (мертвая ссылка)
Один экземпляр контекста, несколько вызовов одного и того же sproc: (мертвая ссылка)
Несколько экземпляров контекста, несколько вызовов одного и того же sproc: (мертвая ссылка)
Вы также можете проверить производительность обновления, удаления и вставки.
Ваш код данных обычно выглядит так? Почему-то это не похоже на настоящий код доступа к данным ... Тестирование циклов не имеет ничего общего с тем, как выглядят реальные шаблоны доступа к данным.
Ответы 3
Я думаю, вам стоит протестировать это несколько иначе, чтобы отличить затраты на запуск против затрат на исполнение. В частности, Entity Framework имеет значительный затраты на запуск из-за необходимости компилировать представления базы данных (хотя вы можете сделать это заранее). Точно так же в LINQ есть понятие скомпилированный запрос, которое было бы подходящим при выполнении запроса несколько раз.
Для многих приложений затраты на выполнение запроса будут более важными, чем затраты на запуск. Для некоторых может быть правдой обратное. Поскольку рабочие характеристики у них разные, я считаю важным их различать. В частности, вводит в заблуждение усреднение затрат на запуск и среднюю стоимость многократно выполняемого запроса.
Но разве эти результаты не отражают, как все будет работать в приложении asp.net? Поскольку я действительно не могу сохранить экземпляр в любом контексте «живым», я должен создавать новый для каждого запроса и вызывать хранимую процедуру.
Нет, не обязательно. Вы можете предварительно скомпилировать представления Entity Framework, и в этом случае вы не платите эти затраты при создании экземпляра контекста. Даже для вещей, которые нельзя предварительно скомпилировать, отслеживание этих элементов по отдельности проясняет разницу между запросом, который выполняет один запрос, и тем, который выполняет 100.
Я сделал несколько тестовых страниц asp.net, пытаясь понять, какая из них работает лучше. Мой тест был:
Удалить 10 000 записей Вставить 10 000 записей Редактировать 10 000 записей Свяжите 10000 записей с GridView и отобразите на странице
Я ожидал, что LinqToSQL будет быстрее, но выполнение вышеуказанного LinqToSQL занимает почти 2 минуты, а LinqToEntities - менее 20 секунд.
По крайней мере, для этого теста кажется, что LinqToEntities быстрее. Мои результаты, похоже, совпадают с вашими.
Я не пробовал вставлять / редактировать / удалять / отображать более одной таблицы, объединенной вместе.
Мне интересно узнать больше ... или, если мой тест не является допустимым типом теста, мне было бы интересно увидеть некоторые настоящие тесты.
Я понимаю, что это старый пост, но если вам все еще интересно, я провел несколько тестов с EF, которые доступны здесь (blog.staticvoid.co.nz/2012/03/entity-framework-comparat ive.html). Я обнаружил, что L2S намного медленнее при обновлении, но мне хотелось бы знать, почему (и есть ли способ его улучшить). L2S был намного быстрее на Selects, хотя
Хорошо сделано. Я далек от эксперта по базам данных и ORM, но мне нравится то, что показали ваши тесты. Я также недавно прочитал статью команды ADO.net об улучшениях EF5: blogs.msdn.com/b/adonet/archive/2012/02/14/…
спасибо, да, команда EF в последнее время делала довольно крутые вещи в отношении производительности, что интересно, большая часть из них, похоже, была сделана внутри dot net 4.5, а не в двоичных файлах EF, что круто, поскольку это дает толчок целому ряду различных технологий.
Похоже, это хорошее измерение производительности между LINQ to SQL и Entity Framework.
http://toomanylayers.blogspot.com/2009/01/entity-framework-and-linq-to-sql.html
Что происходит, когда вы помещаете строки создания контекста в блок using ()? Эти более продолжительные вызовы могут быть из-за того, что система не имеет соединения в пуле ...?