Importing in Java, C# and the like is fundamentally different from including in C and C++:
The former will add the named modules to those considered for symbol resolution, the latter inserts the named headers content literally into the translation unit.
Which means a header can contain anything the source-file can, including translation-unit-local objects (They might have a constructor and destructor in C++), functions, structs (and for C++ classes).
Which is not quite as bad as it sounds for C, as headers tend to mostly contain forward-declarations, struct definitions and preprocessor-macros.
In C++ on the other hand, templates (which are far more powerful than puny Java or C# generics) generally must be implemented in headers, which makes them grow to considerable size and complexity (often outstripping by orders of magnitude the source-file of the translation-unit).
The C++ committee is working on a module-system to take care of that, but at the earliest it will be there in C++17 (and don't hold your breath yet).
So, for the languages with module-system (Java, C#) you will only have a slight slowdown for analysis and compilation.
For C, you will probably only have a slightly higher slowdown, due to literal inclusion of the source, though at least they tend not to be too big and complex.
For C++, you will have a moderate to severe slowdown of compilation and analysis, due to heavy use of templates and inline-functions.
In both C and C++ headers can in theory contain TU-local objects, which would result in some runtime overhead.
While I know that such is used by C++ for
<iostream> (look for
ios_base::Init in the standard) to initialize the C++ streams early enough, I don't know of any use in C.