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.