Speed up compilation in Visual D

[Alex]

On Sunday, 28 April 2019 at 12:22:15 UTC, Rainer Schuetze wrote:
>
>
> On 28/04/2019 13:47, Alex wrote:
>> On Sunday, 28 April 2019 at 08:25:18 UTC, Rainer Schuetze 
>> wrote:
>>>
>>>
>>> On 26/04/2019 09:52, Rainer Schuetze wrote:
>>>>> As if when generating the command line for single file 
>>>>> compilation you forgot to append the additional options 
>>>>> string to it.
>>>> Yes, looks like a bug in Visual D: it adds the additional 
>>>> command line options to the link, but not to the single file 
>>>> compiler invocations.
>>>>
>>>
>>> fixed in https://github.com/dlang/visuald/releases/tag/v0.49.2
>> 
>> Man, it's really slow compiling!
>> 
>> It took over 3 minutes to compile the same project that 
>> compiles in 10 seconds with combined compile.
>
> Yes, it's usually that bad if you have a good number of 
> dependencies
> (imports).
>
>> 
>> Even after compilation of all the object files it takes 10 
>> seconds just to recompile 1 file.
>> 
>
> If a single file needs 10 sec, there are probably quite a few 
> imports. You can check the dep-files in the intermediate 
> directory to see detected dependencies.
>

The .dep file has 800+ lines.

>> There is absolutely no speed up.
>> 
>> Also, I always get
>> 
>> x64\Debug DMD\S.exe not up to date: d:\repos\s\s\x64\debug 
>> dmd\s.exe older than d:\repos\s\s\$(outdir)\g\d\set.obj
>
> That sounds like it is only linking again, though "$(outdir)" 
> in the name looks wrong. Is that really your build directory?
>

Yes, the $outdir is there. I assume it is the x64 or win32 
directory... the message is not expanding the token for some 
reason. I thought it was odd too which is why I posted it.

I simply shortened the directory names since the specific names 
are not important and just add unnecessary characters.

>> and so it has to build this one obj file every time.
>> I'm not sure what is going on here set.d is not being changed 
>> as far as
>> I know.
>> 
>> In any case, unless there is a huge bug in single file 
>> compilation I don't see it being at all faster than combined 
>> compile.
>> 
>
> Combined compilation is preferred in most cases. If you can 
> separate into non-dependent libraries that could help.

The main problem I see with this is a lot of stuff I do is based 
on templates so I don't think it would help? The compiler will 
still have to access the files in the same way and load them to 
parse?

If you think it will significantly help I would try it. But 
shaving off a few % really isn't my goal.

Most of the dependencies are from phobos and gtkD.

about 600 are from gtk and 150 from phobos.

gtkD already uses a dll.

A lot of the modules I'm loading from gtkd are not needed I 
suppose... Do you know of a util that can determine all the 
actual necessary modules a project needs? I could then remove 
those from gtk that are not used. I add them just so I wouldn't 
have to add them later if I needed them but maybe it is slowing 
things down quite a bit.