Вопросы оптимизации
Начальник попросил написать один алгоритм. Язык - C#.
Я реализовал все в лучшем стиле ООП, все разбил по объектам и классам, использовал сортированные списки. Заработало.
Когда начальник проверял код, на меня обрушился шквал критики, зачем я столько все лишнего написал, если здесь не нужны структуры и все данные можно индексировать в одномерных, в худшем случае двумерных, массивах (где не требуется поиск и где можно все находить по индексу). На мой ответ, что я использую инкапсуляцию для читабельности кода и возможности сопровождения, он сказал, что я просто создаю кучу лишних объектов и присваиваний.
Переписал как требует начальник. Ни одной лишней структуры, одни массивы. Работать стало в 1,5 раза медленнее. На что мне начальник сказал, что я над ним издеваюсь.
Как доходчиво объяснить антифанату ООП, почему с массивами работает медленнее (сам не понимаю), и как аргументировать ситуацию в пользу классов и прочих прелестей ООП?
Я реализовал все в лучшем стиле ООП, все разбил по объектам и классам, использовал сортированные списки. Заработало.
Когда начальник проверял код, на меня обрушился шквал критики, зачем я столько все лишнего написал, если здесь не нужны структуры и все данные можно индексировать в одномерных, в худшем случае двумерных, массивах (где не требуется поиск и где можно все находить по индексу). На мой ответ, что я использую инкапсуляцию для читабельности кода и возможности сопровождения, он сказал, что я просто создаю кучу лишних объектов и присваиваний.
Переписал как требует начальник. Ни одной лишней структуры, одни массивы. Работать стало в 1,5 раза медленнее. На что мне начальник сказал, что я над ним издеваюсь.
Как доходчиво объяснить антифанату ООП, почему с массивами работает медленнее (сам не понимаю), и как аргументировать ситуацию в пользу классов и прочих прелестей ООП?
Вы бы ещё исходники приложили, чтобы мы сами оценили и поняли о чём речь.
С исходниками сложно, много кода. Попробую конкретику на словах описать.
Есть словарь. Есть счетчики слов. Есть класс, в котором слово может лежать. Все слова имеют свой id от 1 до N(чтобы со string не работать).
Я решил каждое слово писать в отдельный объект Word, который имеет свойства Id, Statistic, ParentClass. Equals и GetHashCode направлены на сравнение Id.
Создал специальный список слов, который реализует интерфейc IComparable, и комперары для сравнения Word по Id и по Statistic.
Предложение от руководства: создавать массивы, мощность которых будет равна мощности словаря, и индекс этих массивов будет означать Id слова минус один.
Таким образом вместо описанной мной структуры можно создать два массива: один со счетчиками, другой - с айдишниками родительского класса.
Это только первая проблема. Есть аналогичные. Главный принцип - нарушение инкапсуляции, чтобы низший уровень вынести в алгоритм.
Так лучше? Или все таки куча исходников будет лучше?
Есть словарь. Есть счетчики слов. Есть класс, в котором слово может лежать. Все слова имеют свой id от 1 до N(чтобы со string не работать).
Я решил каждое слово писать в отдельный объект Word, который имеет свойства Id, Statistic, ParentClass. Equals и GetHashCode направлены на сравнение Id.
Создал специальный список слов, который реализует интерфейc IComparable, и комперары для сравнения Word по Id и по Statistic.
Предложение от руководства: создавать массивы, мощность которых будет равна мощности словаря, и индекс этих массивов будет означать Id слова минус один.
Таким образом вместо описанной мной структуры можно создать два массива: один со счетчиками, другой - с айдишниками родительского класса.
Это только первая проблема. Есть аналогичные. Главный принцип - нарушение инкапсуляции, чтобы низший уровень вынести в алгоритм.
Так лучше? Или все таки куча исходников будет лучше?
Ооо, анализаторы текста?
Цитата: Phodopus
Ооо, анализаторы текста?
Совершенно верно. Пишем алгоритм разбития слов на классы.
По сабжу: мои структуры победили. Но только из-за лучшего времени работы. Теоретически я так и не смог объяснить, почему происходит именно так. Начальник долго ругался, что это бред, ведь "при работе с массивами мы сразу обращаемся в нужный участок памяти"... Хоть и проблем у меня больше нет, тема все равно не закрыта. Кто-нибудь сможет объяснить, почему массивы работают в 1,5 дольше?
Без кода никто вам ничего объяснять не станет. Однако замечу, что штатный Dictionary<K,T> хранит данные в массивах (ключи и значения). В случае, если массивы достаточно велики, то просадка производительности может быть обусловлена кэш-промахами, плюс ко всему - чем по большему количеству массивов мы размазываем данные тем больше будет проверок границ, осуществляемых рантаймом.
