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