class — C ++ Громоздкие классы для улучшения локальности ссылок?
Должны ли мы организовывать классы, основанные на местности, а не концептуально?
Гипотетически, предположим, что мы пишем программу для моделирования реальной окружающей среды, которая имеет три объекта: автомобиль, дорога и дерево. Традиционный дизайн ООП предлагает концептуально разделить эти 3 отдельных класса.
Но предположим, что автомобильные и дорожные объекты делают миллионы вычислений среди данных и методов своих учеников. Можем ли мы улучшить производительность, смешивая автомобиль и дорогу в классе CarRoad из-за местоположения ссылки? Или, если этот пример слишком абсурден, если бы у нас был другой отдельный класс Wheel, тесно связанный с автомобилем, должны ли мы смешивать классы Car и Wheel вместе, если их ученики очень часто взаимодействуют?
Решение
Я бы не решил, что, если я действительно профилировать две разные версии и сравнивать производительность.
В противном случае я хотел бы попробовать пару вещей, как,
1. Будет ли разумнее, если один из других классов имеет параметр шаблона и передает его, создавая его экземпляр во время компиляции.
2. Поместите один класс в другой класс, но включите все его методы, а также принудительно заставьте его (есть флаг / атрибут компилятора, чтобы фактически заставить его ..), чтобы увидеть, имеет ли сгенерированный двоичный файл несколько другую локализацию.
Просто случайная идея ..
Другие решения
Возможность объединения автомобилей и дорог в один класс зависит от системы, которую вы пытаетесь смоделировать. Никогда не пытайтесь объединяться только для того, чтобы получить хорошее месторасположение (хотя ваша идея — суперфлюэс).
Локальная ссылка становится понятной, когда вы создаете объекты этого класса. Позвольте мне показать вам простой пример:
Предположим, что мы должны выбрать либо вектор, либо карту среди контейнеров.
1) карта предлагает плохую привязку относительно вектора: —
Карта внутренне реализована в терминах сбалансированного бинарного дерева. Таким образом, это означает, что карта наряду с хранением данных также хранит два указателя, то есть левое поддерево и узкое поддерево (также может быть указатель на родителя). Это означает, что для каждого элемента требуется больше места для хранения тех же данных, что и в, скажем, в векторе. Таким образом, в этом случае меньше данных поместится на одной странице виртуальной памяти.
2) вектор предлагает хорошую локацию ссылки: —
Поскольку нет никакой головной боли при хранении указателей вместе с данными в векторе, он может хранить больше элементов на странице по сравнению с картой. И именно поэтому вектор лучше, чем карта с точки зрения местоположения ссылки.