About compiler memory consumption

Puming zhaopuming at gmail.com
Wed Dec 4 20:02:37 PST 2013


On Wednesday, 4 December 2013 at 16:50:45 UTC, Dicebot wrote:
> On Wednesday, 4 December 2013 at 16:41:14 UTC, Puming wrote:
>> Other than diet, is there many other CTFE/template heavy parts?
>
> Also vibe.http.rest and vibe.http.form create really lot of 
> template instances because of heavy usage of reflection + code 
> generation. This is one of domains though that can potentially 
> improve a lot by better compiler implementation,
>

>> I hope there would be a non-CTFE version of diet template, 
>> similar to regex/CTRegex. If we use the non-CTFE version in 
>> dev mode, we would have a better memory & compile time 
>> turnaround in dev mode. And in the release mode the diet 
>> templates would be optimized with CTFE. Is that a viable 
>> approach?
>
> That should be possible and relatively simple (because of CTFE 
> nature a lot of code can be reused). It may considerably impact 
> Diet performance but I can see desire for that in development 
> mode as project size increases. As usual, it is mostly matter 
> of manpower - vibe.d has only one persistent contributor right 
> now and probably 5-8 guys doing occasional pull request, 
> definitely not enough for project of that scale.

There maybe another traditional approach, by converting the .dt 
diet templates directly into D source code BEFORE the actuall 
compilation. That is the way many other HTML template systems 
use, and the performance is fairly good.

The generated D code could be very C like, and does not use much 
CTFE and templates, so that it doesn't incur a lot of compilation 
resources.

As as the matter of manpower, I'm very interested in D/Vibe.d, 
and will learn and try to contribute :-)

I'm currently using Java/Netty&Friends at work. But found 
D/Vibe.d would be a better solution in the future.


More information about the Digitalmars-d-learn mailing list