Our template emission strategy is broken

Johannes Pfau via Digitalmars-d digitalmars-d at puremagic.com
Wed Nov 11 05:44:39 PST 2015


Am Wed, 11 Nov 2015 13:08:06 +0000
schrieb David Nadlinger <code at klickverbot.at>:

> Hi all,
> 
> Kenji and Walter have been working on improving the template 
> emission strategy during the last couple of releases, i.e. 
> whether a template instance is emitted to a given object file or 
> not. Nevertheless, I've been continually hearing complaints from 
> various people with large D code bases (our commercial users and 
> some of the more complex open source projects) that they have 
> problems compiling their code doing anything else than an 
> all-at-once build.
> 
> This of course detracts from what we like to cite as one of D's 
> key advantages, compilation speed, because you cannot exploit the 
> many cores of your build machine anymore, and the 
> edit-compile-debug cycle is slowed down because you have to build 
> the full application every time. But this turns into a severe 
> problem as soon as your compilation does not fit into RAM 
> anymore, which happens quite quickly when using D's advanced 
> features – see for example Liran Zvibel's DConf talk, where he 
> describes that they needed machines with more than 100 GB of RAM 
> in order to build the Weka code base.
> 
> In any case, I hope you agree that fixing these kinds of issues 
> that prevent D code from being compiled all is strategically 
> important for us, since they are a deciding factor in driving 
> widespread adoption. Sadly, the template problems didn't seem to 
> receive a lot of attention beyond quick fixes recently, possibly 
> because they don't occur as readily for smaller projects and if 
> so, are easier to work around.
> 
> With all that out of my system, I'd like to point your attention 
> to a particular template instantiation issue I managed to reduce 
> recently when working with the folks at Weka. It seems like there 
> is a fundamental oversight in the way the code tries to elide 
> repeat code generation of instances – or, of course, I'm just 
> missing something:
> 
> https://issues.dlang.org/show_bug.cgi?id=15318
> 
> This is one particular issue that makes writing "idiomatic D" 
> (which is rather template-heavy) in large code bases hard, but 
> likely not the only one. In fact, I already know about another 
> issue where function-local imports cause semantic analysis not to 
> be properly run on template instances, but I'm still struggling 
> to find a minimal example for the problem. My hope would be that 
> we can clean up this mess soon and replace the current ad-hoc 
> patchwork with a more principled approach. In the process, we 
> should also make sure that all of our assumptions [1] about the 
> compilation process are clearly stated in the documentation, as 
> that frequently leads to confusion among newcomers.
> 
> Best,
> David
> 
> 
> 
> [1] That is: All imported modules must also be compiled into the 
> executable; incremental compilation is only guaranteed to work if 
> precisely the same subsets of modules are compiled every time.


http://forum.dlang.org/thread/n1omke$1bh5$1@digitalmars.com



More information about the Digitalmars-d mailing list