For some time I wondered:
Does having many #includes affect run-time performances in any way? should I avoid using many #includes (when they're not really necessary, but could help) for some reason rather then the affect it has on compilation time?
For example: would it make sense to include a whole library for one function when you could re-invent the wheel at the cost of a few minutes?
#include
Page 1 of 16 Replies - 2162 Views - Last Post: 14 December 2012 - 09:21 AM
Replies To: #include
#2
Re: #include
Posted 04 August 2012 - 02:36 AM
#includes affect compilation time and binary size.
#3
Re: #include
Posted 04 August 2012 - 07:11 AM
Try to include only what you need. Some libraries will break up their interface into multiple headers so you don't need to include the whole library to use just one thing from the library. Some libraries also have a header file that includes all other header files for that library. If you don't need to use the whole library, then just include the specific header you need.
#4
Re: #include
Posted 04 August 2012 - 08:04 AM
no, including anything shouldn't effect run-time performance but it *could* if your compiler doesn't take care of it. it could effect locality if your compiler doesn't place unused code/data out of the way or link time optimization isn't used. modern compilers/linkers take care of this however so it's not an issue.
and now that I think about it, that would only be the case if a lot of static/inline non-template functions were defined in the header; something that's already bad practice.
and now that I think about it, that would only be the case if a lot of static/inline non-template functions were defined in the header; something that's already bad practice.
This post has been edited by ishkabible: 04 August 2012 - 08:07 AM
#5
Re: #include
Posted 04 August 2012 - 10:32 PM

POPULAR
A small caveat about the general statement "including anything shouldn't effect runtime performance". There should be an asterisk there saying something like "as long as the included file doesn't affect the way the compilation unit is compiled or parsed".
Consider accidentally including a header file that has lines like this:
Or a header that says:
I've spent time chasing down one of the latter trying to figure out why a program that was running well suddenly slowed down.
Consider accidentally including a header file that has lines like this:
#define malloc(_x) (OutputDebugString(__FUNCTION__), malloc(_x))
Or a header that says:
#define DEBUG #define _DEBUG #undef NDEBUG
I've spent time chasing down one of the latter trying to figure out why a program that was running well suddenly slowed down.
#6
Re: #include
Posted 13 December 2012 - 04:00 PM
Depends on the library, something like iostream won't hurt you, but cmath,stdio.h etc. can affect runtime, essentially bigger the library, longer it takes. The difference is not USUALLY very noticable unless you import multiple big libraries. So:
[#include iostream]
would run faster than say:
[#include stdio.h;
#include cmath;
etc etc....]
[#include iostream]
would run faster than say:
[#include stdio.h;
#include cmath;
etc etc....]
#7
Re: #include
Posted 14 December 2012 - 09:21 AM
1. iostraem is a huge header that includes almost the entire IO library. stdio and cmath just have a few constants defined in them and some function prototypes
2. As has been established it's not really going to effect performance.
2. As has been established it's not really going to effect performance.
Page 1 of 1
|
|

New Topic/Question
Reply


MultiQuote










|