Объектный пул и CSLA Framework - PullRequest
Новая
       50

Объектный пул и CSLA Framework

0 голосов
/ 06 декабря 2010

У меня есть приложение, которое следует основной методологии в рамках CSLA.В частности, объекты знают, как поддерживать свое состояние и как создавать, обновлять, удалять себя.Класс автомобиля показывает эту идею.

public class Car
{
    public int Color {get;set;}
    public void Drive(){.. Do something Here}
    private Car(){} // Only factory method can create this object
    public static Car New()
    {
        Car car = new Car();
        car.DataFetch();
        return car;
    }
    private void DataFetch()
    { 
        // Fill up this object with values from DB or where ever
        this.Color = repo.valueForColor();
        // ...
    }
}

Приложение создает и уничтожает более 1 миллиона объектов, а число создаваемых объектов при сдвиге влияет на производительность из-за количества выполняемой сборки мусора.Кроме того, многие из этих объектов являются полностью временными и используются для простой передачи данных в хранилище.

Я читал о шаблоне мухи , который, кажется, может удовлетворить мои потребности.И я также читал о Объединение объектов и связанный с ним код .

У меня возникли проблемы с созданием миллиона объектов Car с использованием пула или выводом данных для наименьшего веса в сочетании с принципом Объект должен поддерживать свои собственные данные и доступ к данным .

Есть идеи, как этого добиться?

1 Ответ

1 голос
/ 06 декабря 2010

Убедитесь, что ваше поколение объектов действительно влияет.Генерация объектов и GC - это CHEAP на сервере SQL, и у вас есть база данных.Я уверен, что ap rofilder покажет вам, что НЕ ОБРАБОТКА И УНИЧТОЖЕНИЕ ОБЪЕКТОВ влияют на вашу производительность, но в первую очередь тянут 1 миллион объектов.

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

Особенно со смешным неэффективным кодом типа

this.Color = dataReader.get ("Color");

, которыйявляется хештаблическим lokoup для каждой машины.Как насчет хранения индекса поля (или, зная его, он не изменяется между запусками sql) и использования индекса?Одно это принесет вам больше, чем любой другой подход.Особенно, если yuo также выдает миллион отдельных операторов SQL - как вы, похоже, делаете.

Как всегда при выполнении оптимизации производительности: ЗАПУСТИТЕ ПРОФИЛЬ.В вашем случае вы на 100% ошибаетесь в том, что теряете время.Вы обнаружите, что создание объектов и gc даже не отображаются в топ-10 потерь производительности.

...