Перехватчики членов и базовые перехватчики в навязчивых структурах данных
Я кодирую навязчивую структуру данных и задаюсь вопросом, использовать ли базовые или членские хуки. Поскольку код будет вызываться много раз, мой вопрос касается производительности и степени, в которой компиляторы могут встроить такой код.
Базовые хуки основаны на наследовании, в то время как хуки членов используют указатели на члены через параметры шаблона. Мой выбор дизайна - использование хуков-членов, но мой опыт говорит, что указатели гораздо сложнее оптимизировать, чем статический код. С другой стороны, все эти указатели известны во время компиляции, и, возможно, компилятор может сделать некоторую магию, чтобы проанализировать, что происходит.
У кого-нибудь есть опыт с этим? Любые данные, подсказки или ссылки приветствуются.
2 ответа
Что касается большинства "X против Y, что быстрее?" На этот вопрос есть только один правильный ответ:
Задайте свой профиль.
Опыт неясен. Человеческое предположение не может принять во внимание все мелкие детали и подводные камни оптимизации компилятора. Компиляторы отличаются тем, что они могут оптимизировать и насколько хорошо они это делают. Иногда даже между разными версиями одного и того же компилятора. Единственное, что может вам хорошо сказать, как ваши реализации могут быть оптимизированы вашим конкретным компилятором (ами) на вашей конкретной платформе (ах), - это правильное измерение производительности с типичными размерами проблем.
Даже если есть кто-то, кто говорит вам, что он знает, что быстрее, и дает вам несколько симпатичных графиков: можете ли вы доверять ему настолько, чтобы не проводить эти измерения? Он знает, как выглядит ваша конкретная среда? Учитывает ли он и его графики особые угловые случаи ваших проблем? Скорее всего нет.
Поскольку данные и хуки находятся в "имеет" отношение, я бы также предпочел хуки членов с точки зрения дизайна. Я также не думаю, что есть разница в оптимизации между размещением хуков в базовом классе и их непосредственным добавлением в класс.
Также есть некоторые соображения об этих различных подходах в интрузиве Boost.