On 12/11/18 12:39 PM, H. S. Teoh wrote:
On Tue, Dec 11, 2018 at 09:58:39AM +0000, Atila Neves via
Digitalmars-d-announce wrote:
On Monday, 10 December 2018 at 22:18:28 UTC, Neia Neutuladh wrote:
[...]
In typical D code, it's usually faster to compile per package than
either all-at-once or per module. Which is why it's the default in
reggae.
Yeah, for projects past a certain size, compiling per package makes the
most sense.
[...]
From discussions on IRC about reducing compile times, though, using
Phobos is a good way to get slow compilation, and I use Phobos. That
alone means incremental builds are likely to go long.
Yes. Especially with -unittest.
We've talked about this before. Jonathan Marler actually ran a test and
discovered that it wasn't something *directly* to do with unittests; the
performance hit was coming from some unexpected interactions with the
way the compiler instantiates templates when -unittest is enabled. I
don't remember what the conclusion was, though.
I remember:
1. When unittests are enabled, -allinst is enabled as well.
2. This means that all templates instantiated are included as if they
were part of the local module.
3. This means that they are semantically analyzed, and if they import
anything, all those imports are processed as well
4. Recurse on step 2.
Note that the reason allinst is used is because sometimes templates
compile differently when unittests are enabled. In other words, you
might for instance get a different struct layout for when unittests are
enabled -- this prevents that (but only for templates of course).
The ultimate reason why the PR (which removed the -allinst flag for
unittests) was failing was because of differences in compiler flags for
different modules during unittests in Phobos. This caused symbol name
mangling changes (IIRC, mostly surrounding dip1000 problems).
I really wish we could have followed through on that PR...
-Steve
