proposal: lazy compilation model for compiling binaries

Timothee Cour thelastmammoth at gmail.com
Mon Jun 24 02:36:22 PDT 2013


On Mon, Jun 24, 2013 at 1:52 AM, OlliP <jeti789 at web.de> wrote:

> This is now a bit confusing to me. I just made up my mind to go
> with D instead of Go, because Go is too simplistic in my opinion.
> Furthermore, calling C from D is a lot easier than from Go. And
> now this ... I have too little understanding of D to see what the
> impact of this build time issue is. Does this mean build times
> come close to what they are in C++ or is this issue only about
> builds not being as fast as the D people are used to ..?
>
> Thanks, Oliver
>
>
>
> On Saturday, 22 June 2013 at 04:45:31 UTC, Timothee Cour wrote:
>
>> A)
>> Currently, D suffers from a high degree of interdependency between
>> modules;
>> when one wants to use a single symbol (say std.traits.isInputRange), we
>> pull out all of std.traits, which in turn pulls out all of
>> std.array,std.string, etc. This results in slow compile times (relatively
>> to the case where we didn't have to pull all this), and fat binaries: see
>> example in point "D)" below.
>>
>> This has been discussed many times before, and some people have suggested
>> breaking modules into submodules such as: std.range.traits, etc to
>> mitigate
>> this a little, however this requires people to change 'import std.range'
>> to 'import std.range.traits' to benefit from it, and also in many cases
>> this will be ineffective.
>>
>> B)
>> I'd like to propose something different that can potentially dramatically
>> reduce compile time/binary size, while not requiring users to scar their
>> source code as above.
>> ....
>>
>

see timings in my original post above or try for yourself, it is already
much faster than C++ (and even go as reported by some). But I'm talking
here about a proposal to enable interactive time for compiling projects (ie
even faster and using less memory).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130624/0d7ce9be/attachment.html>


More information about the Digitalmars-d mailing list