I've started working on a project that has a shed load of imports in the pch file.
Why would someone do this? Lazyness?
I guess if I refactor them out, I could potentially decrease compile times..... is that so?
No, not unless it's importing things that are changing frequently. The point of the precompiled header is that it combines lots of code that changes very infrequently into an intermediate format to decrease compilation times. If you take stuff out, it has to process each of the imports normally instead of using the intermediate format.
Taking things out of the precompiled header generally slows down the compile times. The exception to this is if you are importing stuff that you are changing on a regular basis, as this would defeat the purpose of it by forcing it to compile it each time.
Related
Alright so I'm using the "Catch2" framework for C++ Unit Testing and in my "testMain.cpp" (Doesn't matter) I include the single header version of it #include "Catch.hpp".
The problem is every time I write just a small test, I have to compile the program in order to see the outputs again. But the single header is something like 70000 lines and it takes FOREVER.
I understand that with source files you can simply compile them into object files and after that link them. So if you are using the same source file for just linking there is no really a need to recompile it over again.
So the point of this question is, Is it possible to somehow compile the Catch.hpp file and just use it as a link after words? Or in order to slow it down do I have to get the multi-header version of the framework?
Thanks in Advance!
Have you read https://github.com/catchorg/Catch2/blob/devel/docs/slow-compiles.md ?
It is recommended to move the tests main function to a separate file, so that the compile intensive parts are only compiled once.
In my new project I have to deal with some Pro*C code and as a part of the project require to compile the entire code as there is a minor change in a header file. Now, to incorporate the changes I will have or recompile the entire application code, which I did. However the sizes of the new executable do not match the old ones, even for the code where the header file is not used.
Can someone help ?
Why do you think that even if you make some changes to the code, the executable will be of same size ? It can vary. Please check if the changes you made to the code are not making any difference to the existing functionality of the code rather than checking the size of the exe file.
AppCode has a feature to "Optimise imports".
It will take redundant or unused imports and remove them and reshuffle them etc...
I can see why it can be done... If you have 3 files A, B and C...
A imports B
C import A and B
In this case you can remove the import of B in C.
But what does it do to the project when these redundant imports build up? Can it slow the build? Does it affect the product?
In the case of redundant imports, it's mostly to reduce code noise (i.e. unneeded lines of code). There isn't a dramatic additional cost to importing the same file twice. include does have a non-trivial cost because it has to open and read the file (even if it uses #ifdef guards), but import tries to avoid that. Even so, there's a small cost there.
Importing a file that you don't use can have a large build-time cost. In C-like languages, importing means "read the whole file and all of its included files and parse them right here." That can be very expensive. There are some tricks to avoid it being exactly that bad (particularly precompiled headers), but it's bad. So getting rid of unused imports is definitely good for build times.
Neither should have any impact on the final product. If it did, then AppCode would be removing a header it should not have removed.
Some of this changes with the new #import syntax, which doesn't require reading and parsing all the header files for modules. But you'd still want to avoid importing headers you don't need for tidiness if nothing else.
Is it recommended to refer to all my header file in Prefix.pch, and then I do not have to type #import headers during development?
I wouldn't recommend this.
The main reason is, header files can change in the course of your development. If you change one header, it will cause the pch to dirty, have to be rebuilt, and now your entire project will rebuild. That's quite time-consuming, and works counter to the whole reason for pch files.
Same thing if you create a new header file, add it to the pch, and now that triggers and entire rebuild.
But there's no single answer here. You may have a 3rd party library that will never (or rarely) change, is quite header-intensive, and so precompiling it may be a way to reduce build times. Experiment and see.
Pre-compiled header files were brought to serve one purpose: to make compiling faster. It is compiled and stored in cache, and automatically included in every source file during the compilation time. Its like each source file does,
#import "Prefix.h"
This can be handy for project-wide #defines. (FYI, #defines are a code smell)
Xcode quotes:
Precompiling the prefix header will be most effective if the contents
of the prefix header or any file it includes change rarely. If the
contents of the prefix header or any file it includes change
frequently, there may be a negative impact to overall build time.
More clear explanation is here
Please keep this in mind when you #import source file header in .pch. As a tip, you can use Prefix.h for #import of constants and utility source files.
From a standards perspective, your includes should be as minimal as possible. Indeed, you shouldn't include anything you don't require for compilation into any file. So, in each of your .h files you should primarily include the superclass and use #class for all other references, then include only in your .m files. This gives the clearest information about the requirements of each class / file and minimises circularity issues.
You should add header file to Prefix.pch just if you need that file/class in most of your other classes. If you need the header file just in one or two other classes it's not point to add it to .pch because it will takes more time for compiler to compile the files and it will happen every time you want to run your project.
I add all the headers to Prefix.pch, and I have to claim life is much easier since that time. I just do not have to import always headers, believe me, life is much easier. :-)
I see that the less.app (on the mac) supports backwards importing
In LESS CSS can I get LESS to watch a bunch of files but compile a different file when they change?
So if I have a global.less that imports an inner less file, it will recompile the global less file, when I change the inner file.
Does anyone know of a way to do this using the less.js in browser compiler? Or is that impossible?
Or probably even better, a windows based compiler that would do this or be able to watch the folder but just compile the global file when any of the folders change.
So far I've tried winless, the less parser and simpless and neither of these will do this. Even if it comiled all the less files to when anything changes in the folder I'd be happy.
Much appreciated!
Support for automatic backwards #import compiling has been added to WinLess in version 1.1.0.