www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - slow compilation speed

reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
When I build dcollections without unit tests, compilation takes less than  
a second.  Although, all the classes/interfaces/structs are templated, so  
there is very little actually generated code.

When building unit tests, I have 8 collection types.  Each type is built  
with 8 integer types (unsigned/signed 8bit, 16bit, 32bit, and 64bit).

With unit tests (no optimization), compilation takes well over a minute.

I don't really understand what is consuming the cycles to compile, but I  
do note that the resulting binary (that just does unit tests on  
dcollections) is 10MB.

Does anyone else have similar results?  I don't think it's the spell  
checker this time, because there are no errors :)

I don't really know how to file a "bug" on this, because I don't know how  
to narrow down the problem.  All I can say is, try compiling dcollections  
with unit tests (can be done via build-lib-linux.sh unittest script in the  
root dcollections directory).  And yes, I'm compiling all files at once.

And use the d2 branch version.

-Steve
Jul 02 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Steven Schveighoffer wrote:
 I don't really understand what is consuming the cycles to compile, but I 
 do note that the resulting binary (that just does unit tests on 
 dcollections) is 10MB.
Try generating a .map file and look and see what is in the executable.
Jul 02 2010
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 02 Jul 2010 21:15:06 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:

 Steven Schveighoffer wrote:
 I don't really understand what is consuming the cycles to compile, but  
 I do note that the resulting binary (that just does unit tests on  
 dcollections) is 10MB.
Try generating a .map file and look and see what is in the executable.
I did. There are 67,000 lines in that file. I'm not sure what I'm supposed to be looking for... I ran it with -v, and I found that the part that takes the most time is something that prints "function ..." continuously (replacing ... with lots of different functions) The link step is not fast either (it takes a good 10-15 seconds), but I guess that's to be expected, see below... I did see some symbols that were outrageously long like: _D892TypeInfo_S3std8typecons860__T5TupleTS12dcollections4Hash387__T4HashTS12dcollections7HashMap16__T7HashMapTiTkZ7HashMap7elementS126_D12dcollections7HashMap16__T7HashMapTiTkZ7HashMap13_hashFunctionFKS12dcollections7HashMap16__T7HashMapTiTkZ7HashMap7elementZkS186_D12dcollections7HashMap16__T7HashMapTiTkZ7HashMap15_updateFunctionFKS12dcollections7HashMap16__T7HashMapTiTkZ7HashMap7elementKS12dcollections7HashMap16__T7HashMapTiTkZ7HashMap7elementZvZ4Hash8positionTS12dcollections4Hash387__T4HashTS12dcollections7HashMap16__T7HashMapTiTkZ7HashMap7elementS126_D12dcollections7HashMap16__T7HashMapTiTkZ7HashMap13_hashFunctionFKS12dcollections7HashMap16__T7HashMapTiTkZ7HashMap7elementZkS186_D12dcollections7HashMap16__T7HashMapTiTkZ7HashMap15_updateFunctionFKS12dcollections7HashMap16__T7HashMapTiTkZ7HashMap7elementKS12dcollections7HashMap16__T7HashMapTiTkZ7HashMap7elementZvZ4Hash8positionZ5Tuple6__initZ Yeah, that's 955 characters long :) With template abilities, and all symbols containing their module names, this gets to be ridiculously long. I wonder, can symbol names be encoded with some sort of definition? That is, through some special character sequence, the symbol defines a frequently used term in the symbol (like 'dcollections' in my example) and associates it with a special 1-2 character abbreviation, and then uses the abbreviation throughout instead of the fully-expanded name? It will be less readable without demangling, but I think even with demangling, the symbol above will be unreadable. All we need to come up with is standard rules of when to encode names (so different compilers generate the same symbols). -Steve
Jul 08 2010