Почему Код EF4 является Первым настолько медленный, храня объекты?

Я в настоящее время провожу некоторое исследование на использовании db4o устройство хранения данных для моего веб-приложения. Я довольно счастлив, как легкий db4o работает. Таким образом, то, когда я читал о Коде, Сначала приближаются, мне отчасти понравилось, потому что способ работать с Кодом EF4 Сначала весьма схож с работой с db4o: создайте свои объекты области (POCO's), бросьте их в db4o и никогда не оглядывайтесь назад.

Но когда я сделал сравнение производительности, EF 4 был ужасно медленным. И я не мог выяснить почему.

Я использую следующие объекты:



public class Recipe { private List _RecipePreparations; public int ID { get; set; } public String Name { get; set; } public String Description { get; set; } public List Tags { get; set; } public ICollection Preparations { get { return _RecipePreparations.AsReadOnly(); } }

    public void AddPreparation(RecipePreparation preparation) 
    {
        this._RecipePreparations.Add(preparation);
    }
}

public class RecipePreparation { public String Name { get; set; } public String Description { get; set; } public int Rating { get; set; } public List Steps { get; set; } public List Tags { get; set; } public int ID { get; set; } }

Проверить производительность I новый рецепт и добавить 50 000 RecipePrepations. Затем я хранил объект в db4o как так:

IObjectContainer db = Db4oEmbedded.OpenFile(Db4oEmbedded.NewConfiguration(), @"RecipeDB.db4o");
db.Store(recipe1);
db.Close();

Это берет приблизительно 13 000 (мс)

Я снабжаю материал EF4 в SQL Server 2008 (Экспресс, локально) как это:

cookRecipes.Recipes.Add(recipe1);
cookRecipes.SaveChanges();

И это берет 200.000 (мс)

Теперь, как же db4o 15 (!!!) времена быстрее это EF4/SQL? Я пропускаю секретную турбо кнопку для EF4? Я даже думаю, что db4o мог быть сделан быстрее? Так как я не инициализирую файл базы данных, я просто позволяю ему вырасти динамично.

12
задан Saab 27 July 2010 в 11:41
поделиться

3 ответа

EF превосходит многие вещи, но массовая загрузка не входит в их число. Если вам нужна высокопроизводительная массовая загрузка, выполнение ее напрямую через сервер БД будет быстрее, чем любой ORM. Если единственным ограничением производительности вашего приложения является массовая загрузка, вам, вероятно, не следует использовать EF.

1
ответ дан 2 December 2019 в 23:06
поделиться

Вы вызывали SaveChanges() внутри цикла? Неудивительно, что это медленно! Попробуйте сделать так:

foreach(var recipe in The500000Recipes)
{
    cookRecipes.Recipes.Add(recipe);
}
cookRecipes.SaveChanges();

EF ожидает, что вы сделаете все нужные вам изменения, а затем вызовете SaveChanges один раз. Таким образом, он может оптимизировать взаимодействие с базой данных и sql для выполнения изменений между состоянием открытия и состоянием сохранения, игнорируя все изменения, которые вы отменили. (Например, добавление 50 000 записей, затем удаление половины из них, затем нажатие SaveChanges добавит в базу данных только 25 000 записей. Никогда.)

3
ответ дан 2 December 2019 в 23:06
поделиться

Просто чтобы добавить к другим ответам: db4o обычно запускается внутри процесса, а EF абстрагирует внепроцессную базу данных (SQL). Однако db4o по сути однопоточный. Таким образом, хотя этот пример может быть быстрее с одним запросом, SQL будет обрабатывать параллелизм (несколько запросов, несколько пользователей) намного лучше, чем настройка базы данных db4o по умолчанию.

1
ответ дан 2 December 2019 в 23:06
поделиться
Другие вопросы по тегам:

Похожие вопросы: