Hiệu suất C++, tối ưu hóa trình biên dịch, chức năng trống trong .cpp

Question

Tôi có một lớp rất cơ bản, đặt tên là Basic, được sử dụng trong hầu hết các tệp khác trong một dự án lớn hơn. Trong một số trường hợp, cần phải có đầu ra gỡ lỗi, nhưng trong chế độ phát hành, điều này không nên được kích hoạt và là một NOOP.

Hiện tại có một xác định trong tiêu đề, nút này sẽ bật hoặc tắt makro, tùy thuộc vào cài đặt. Vì vậy, đây chắc chắn là một NOOP, khi tắt. Tôi tự hỏi, nếu tôi có mã sau đây, nếu một trình biên dịch (MSVS/gcc) có thể tối ưu hóa ra các cuộc gọi chức năng, để nó lại là một NOOP. (Bằng cách đó, chuyển đổi có thể ở trong .cpp và chuyển đổi sẽ nhanh hơn nhiều, biên dịch/liên kết thời gian khôn ngoan).

--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

Như với tất cả các câu hỏi như thế này, câu trả lời là - nếu nó thực sự quan trọng với bạn, hãy thử cách tiếp cận và kiểm tra ngôn ngữ lắp ráp được phát ra.

Answer 2

Trình biên dịch có thể tối ưu hóa mã này, nếu nó biết việc triển khai hàm printDebug tại thời gian biên dịch. Nếu printDebug nằm trong một mô-đun đối tượng khác, điều này có thể chỉ được tối ưu hóa bởi trình liên kết, sử dụng tối ưu hóa toàn bộ chương trình. Nhưng cách duy nhất để kiểm tra điều này là đọc mã Assembly được tạo bởi trình biên dịch. Nếu bạn đã có PRINT_DEBUG vĩ mô, bạn có thể mở rộng nó bằng cách này như TRACE được định nghĩa:

 
#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, tại sao không sử dụng tiền xử lý vĩ mô khác nhau?

Chỉ trong top đầu của tôi, một cái gì đó như:

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

Answer 4

Hiện nay hầu hết các tối ưu hóa được thực hiện tại thời gian biên dịch. Một số trình biên dịch là LLVM có thể tối ưu hóa tại thời gian liên kết. Đây là một ý tưởng thực sự thú vị. Tôi đề nghị bạn hãy xem.

Đang chờ các loại tối ưu hóa này, những gì bạn có thể làm là như sau. Xác định macro cho phép bạn bao gồm câu lệnh sau tùy thuộc vào việc DEBUG có được xác định hay không.

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

Bạn có thể sử dụng nó như thế này

Basic() { 
     simpleSetupCode; 

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

mà đã nhiều dễ đọc hơn so

Basic() { 
     simpleSetupCode; 

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

Lưu ý rằng bạn có thể sử dụng nó như thể nó là một từ khóa

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

Answer 5

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

Bằng cách này, bộ tiền xử lý sẽ loại bỏ tất cả các mã gỡ rối trước khi nó đến trình biên dịch.