April 28, 2019 Re: Speed up compilation in Visual D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Rainer Schuetze | 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. |
Copyright © 1999-2021 by the D Language Foundation