Объединение объектов и фреймворк CSLA

У меня есть приложение, которое следует базовой методологии в рамках 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 с использованием пула или извлечением данных для легковеса в сочетании с принципом Объект должен поддерживать свои собственные данные и доступ к данным.

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


person Brig    schedule 06.12.2010    source источник


Ответы (1)


Убедитесь, что создание вашего объекта действительно влияет. Генерация объектов и сборщик мусора - ДЕШЕВО на сервере sql, и у вас задействована база данных. IO уверен, что ap rofilder покажет вам, что на вашу производительность влияет НЕ создание и разрушение объектов, а, в первую очередь, получение 1 миллиона объектов.

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

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

this.Color = dataReader.get ("Цвет");

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

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

person TomTom    schedule 06.12.2010
comment
Это всего лишь образец кода. На самом деле я не получаю данные. Точный тест, который я описал, просто повторял i ‹int.MaxValue (); я ++ - person Brig; 06.12.2010