Compilation Performance: modules or libraries

[Maxime_Cabanal]

Hello,

I would like to have some insights about the performance of the compilation process with IFX regarding medium-big projects (I guess that depends on the person talking but here we are at about 2500 f90 files, for an current compilation time of 17minutes).

I wanted to know if there are some general rules about speeding up the compilation, in particular:

- does a "unity build" change anything? (the fact to include every source file in a unique "main.f90" file to just have one big file instead of a bazillion little to speed up disk access and maybe some whole program optim)

- When we split the code into independant/quasi-independant modules, is it better to keep these modules in the same project (vfproj file) - is IFX capable of a good parallelization inside of a project? - or to split them into another static library project so that we can have a parallelization at a higher level (by msbuild doing the orchestration)?

If you have any other tips, they are welcome!

Thank you

Regards

[andrew_4619]

Well I do not know the optimum answer to all these questions but I will note:

1] Very large source files I have found in the past to be slower. At some magic size things slow down a lot. That makes sense when you think that the compiler has to catalogue and search more things so there is maybe some "n squared"  and also maybe system memory/resource limits.

2] After universally adopting the use of sub-modules I no long really care about build speed as dependency build cascades are now a thing of the past.

3] Having things in the same solution and defining project dependencies can reduce unnecessary builds as can selectively unloading top level projects in the solution that have dependencies but you do not need to be built at the current time.

[Maxime_Cabanal]

2) I see, can you develop a bit on the use of sub-modules? I think one or our developers began using them to have module subroutine, but I fail to see at the moment how this can be so much beneficial.

You are talking about the case when you are updating code which lives inside of a submodule and that does not affect their siblings?

3) At visual studio level, if you unload a project, it will not be built, so if there is a dependency, you will be linking against an old version, right?

On this point I was thinking that maybe it is easier for visual studio to parallelize the projects than for IFX at source level, so you could have move leaf projects being built concurrently at the same time.

[andrew_4619]

Well a submodule has parts, the module that has interfaces to routines that are used externally and the submodule(s). The submodule(s) actually has the routines. If you make changes to the submodule routines (that do not change the interfaces) then the only thing that needs to be re-compiled is the submodule, but with a plain module  anything  that uses the module needs to be compiled and if any of those things are modules then anything that uses those needs to be compiles and before you know it you are compiling 90% of the project because you made one small change! Submodules are brilliant but take some wort to set up.

With the unloading project a meant unload projects that have no upstream dependencies. An example where you have a number of projects that rely on the library which is also a project in the solution. If you change the library then all the dependencies of the library get built, but some of those may not be of interest today.