Производительность C++, оптимизирующий компилятор, пустая функция .cpp

Question

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

В настоящее время в заголовке есть определение, которое включает или выключает макрос в зависимости от настройки. Так что это определенно NOOP, когда выключен. Мне интересно, если у меня есть следующий код, если компилятор (MSVS/gcc) может оптимизировать вызов функции, так что он снова является NOOP. (Делая это, коммутатор может быть в .cpp, и переключение будет намного быстрее, время компиляции/соединения).

--Header-- 
void printDebug(const Basic* p); 

class Basic { 
    Basic() { 
     simpleSetupCode; 

     // this should be a NOOP in release, 
     // but constructor could be inlined 
     printDebug(this); 
    } 
}; 
--Source-- 
// PRINT_DEBUG defined somewhere else or here 
#if PRINT_DEBUG 
void printDebug(const Basic* p) { 
    // Lengthy debug print 
} 
#else 
void printDebug(const Basic* p) {} 
#endif 

Answer 1

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

Answer 2

Возможно, компилятор может оптимизировать этот код, если он знает реализацию функции printDebug во время компиляции. Если printDebug находится в другом объектном модуле, возможно, это может быть оптимизировано только компоновщиком, используя всю оптимизацию программы. Но единственный способ проверить это - прочитать код сборки, сгенерированный компилятором. Если у вас уже есть PRINT_DEBUG макрос, вы можете продлить его, кстати, как TRACE определяется:

 
#define PRINT_DEBUG // optional 
#ifdef PRINT_DEBUG 
#define PRINT_DEBUG_CALL(p) printDebug(p) 
#else 
#define PRINT_DEBUG_CALL(p) 
#endif 


void printDebug(const Basic* p); 

class Basic { 
    Basic() { 
     simpleSetupCode; 

     // this should be a NOOP in release, 
     // but constructor could be inlined 
     PRINT_DEBUG_CALL(this); 
    } 
}; 
--Source-- 
// PRINT_DEBUG defined somewhere else or here 
#if PRINT_DEBUG 
void printDebug(const Basic* p) { 
    // Lengthy debug print 
} 
#endif 

Answer 3

errm, почему бы не использовать препроцессор макросов по-разному?

Только в верхней части моей головы, что-то вроде:

#define DEBUG_TRACE(p) 
    #ifdef PRINT_DEBUG 
    printDebug(p); 
    #else 
    ; 
    #endif 

Answer 4

В настоящее время большинство оптимизаций выполняются во время компиляции. Некоторые компиляторы, такие как LLVM, могут оптимизировать время ссылки. Это действительно интересная идея. Я предлагаю вам взглянуть.

Ожидая такой оптимизации, вы можете сделать следующее. Определите макрос, который позволяет включать следующий оператор в зависимости от того, определен ли DEBUG или нет.

#ifdef DEBUG 
#define IF_DEBUG (false) {} else 
#else 
#define IF_DEBUG 
#endif 

чем вы можете использовать его как это

Basic() { 
     simpleSetupCode; 

     // this should be a NOOP in release, 
     // but constructor could be inlined 
     IF_DEBUG printDebug(this); 
    } 

, которая уже гораздо более читабельным, чем

Basic() { 
     simpleSetupCode; 

     // this should be a NOOP in release, 
     // but constructor could be inlined 
#if DEBUG 
     printDebug(this); 
#endif 
    } 

Обратите внимание, что вы можете использовать его, как если бы это было ключевое слово

IF_DEBUG { 
    printDebug(this); 
    printDebug(thas); 
} 

Answer 5

#if PRINT_DEBUG 
#define printDebug _real_print_debug 
#else 
#define printDebug(...) 
#endif 

Таким образом препроцессор будет деактивировать весь отладочный код, прежде чем он даже попадет в компилятор.