• ParticlePeter (92/92) Jul 05 2014 Hello community,

"ParticlePeter" <ParticlePeter gmx.de> writes:

Hello community,

here is a post with multiple questions regarding compile times, 
or rather the optimization of the compile and link process. I 
work with VisualD and am interested in optimizing my projects 
with this utility, hence there will be a similar topic linking 
here, where I explain my solution an projects setup.
One of the advertised advantages of D is compiler speed. Hence I 
think that I do some mistakes, as my ( hobby ) projects consist 
of a quite small code base. The more I learn about the language, 
the more features I use, the more my compile times increase. I 
guess my usage of these features, template in particular, are not 
well designed.

Question 1)
How can I profile my compile times ? I have some guesses, but 
they might be wrong.

Question 2)
Is there a good read about the intermediate files dmd creates 
(e.g. *.obj, *.def), and how they might be utilized to improve 
compile times ( incremental compilation? ) ?

Next I need to explain some details about my codebase:
I use a lib, lets call it MyLib, which consists of about 15 
modules, each 300 lines of code in average. Most of the modules 
consist of one class and some of these classes have one or two 
template methods. I link this lib statically to another ( one ) 
lib I created from some DerelictOrg modules. Projects which use 
MyLib consist of about five modules which have aprox 200 lines of 
code in average. I would say this is a small codebase.
I use MyLib all of these projects, and about the time I 
introduced template methods in MyLib I noticed a slow down in 
compiling and linking ( but I cannot tell for sure that the 
compile time is related to the template method, however lets 
assume it is ). Before that my projects used to build in five 
seconds max, now it is more like 30 seconds, and most of the time 
is spend in building MyLib. My guess is that MyLib is completely 
rebuild when I use it in a projects with differently typed calls 
to the template methods.

Question 3)
How smart is dmd in separating template from non-template code, 
in particular if both codeblocks are defined in the same module / 
class ?
How can I assist dmd in determining and/or keeping files 
necessary for incremental compilation and linking ?

One step deeper into MyLib. All the template methods have only 
one type parameter. I use arbitrary typed Arrays, generate some 
information about the type with compile time reflection ( 
primitive and struct types ), and call a non-template method 
which takes a void[] array and the extracted type information. 
That made me think about GOF Decorator pattern via UFCS. 
Unfortunately, I guess due to the restrictions mentioned in the 
docs for UFCS ( , I do not get it to work. Here is my approach:

/// file LibModule.d
module LibModule;

struct TypeDescriptor { ... }

class NonTemplate {
	void nonTemplateMethod( void[] array , TypeDescriptor 
typeDescriptor )
	{ ... }
}

void templateFunction(T)( NonTemplate nonTemplate , T[] array ) {
	auto typeDescriptor =  ... /// mindblowing compile-time magic
	nonTemplate.nonTemplateMethod( array , typeDescriptor );
}

...

/// Usage in file MainModule.d
module MainModule;

import LibModule;

float[100] floatArray;
auto nonTemplate = new NonTemplate;
nonTemplate.templateFunction( floatArray );
...


Question 4)
This does not work, how can I make it work ?
It also did not work with a separate module TemplateModule for 
templateFunction, tried to import TemplateModule in LibModule as 
well as in MainModule.

Question 5)
Would this improve my compilation speed at all ?
How would I compile and link only non template modules/classes in 
my lib and still be able to use templateFunction in the described 
UFCS way ?

The following question is valid if only I get answer like: Not 
possible due to UFCS restrictions
Specification of UFCS is presented with an example explaining the 
restrictions, which quite confuses me:

Question 6)
The example given as reasoning to UFCS restrictions, isn't that 
using symbol shadowing, which is deprecated ?
How could Walter and Andrei be asked politely to loosen these 
restrictions, as the gain in functionality is significant 
compared to the ( unlikely ? ) example scenario ?

Thanks in advance for any advice.

Cheers, ParticlePeter