H. S. Teoh wrote:

> The problem is not the Phobos implementation.  The problem is that the
> compiler's way of handling templates and CTFE needs to be improved.  We
> seriously need to muster some manpower to help Stefan finish newCTFE,
> and then we need to take a serious look at improving the current
> implementation of templates.

yeah, i'm not saying that phobos code is wrong. but being "not wrong" and being fast is not always the same. ;-)

>> still, we can be either smart, or have fast compile times, but not
>> both. T_T
> [...]
>
> I'll like to disagree. :-D  There's got to be a way to do this that
> doesn't have to compromise either way.  I mean, this is not like we're
> doing rocket science here, or solving an NP complete problem.  It's a
> straightforward way of recognizing a particular code pattern and
> applying 1-to-1 mappings.  The general case of completely arbitrary
> templates can still fallback to the current implementation.  The point
> is to optimize for specific template usage patterns that are common and
> yields big speedups, but still leave the door open for weirder, but less
> common, template code.

but until that brave new world materializes, we have a smart/fast dilemma. alas.

On Mon, Feb 26, 2018 at 10:12:25PM +0200, ketmar via Digitalmars-d wrote: [...]
> but until that brave new world materializes, we have a smart/fast dilemma.  alas.

I'd like to contribute to the materialization of that brave new world. Rather than sit around and wait for it to happen.  :-P


T

-- 
Your inconsistency is the only consistent thing about you! -- KD

H. S. Teoh wrote:

> On Mon, Feb 26, 2018 at 10:12:25PM +0200, ketmar via Digitalmars-d wrote:
> [...]
>> but until that brave new world materializes, we have a smart/fast
>> dilemma.  alas.
>
> I'd like to contribute to the materialization of that brave new world.
> Rather than sit around and wait for it to happen.  :-P

i'd like to do it too, but dmd code to process templates knocks me out of my consciousness. alas.

On Monday, 26 February 2018 at 21:38:09 UTC, ketmar wrote:
> H. S. Teoh wrote:
>
>> On Mon, Feb 26, 2018 at 10:12:25PM +0200, ketmar via Digitalmars-d wrote:
>> [...]
>>> but until that brave new world materializes, we have a smart/fast
>>> dilemma.  alas.
>>
>> I'd like to contribute to the materialization of that brave new world.
>> Rather than sit around and wait for it to happen.  :-P
>
> i'd like to do it too, but dmd code to process templates knocks me out of my consciousness. alas.

Yes, the dmd template is seriously mind-blowing.

Which is why I am building an alternative system, which is aimed at being fast.
At the expensive of the programmer though, because there is no automatic caching.
If you want to "instantiate" the same "template-replacement" if the same parameter you better know that in advance.

On Tuesday, 27 February 2018 at 08:49:15 UTC, Stefan Koch wrote:
> On Monday, 26 February 2018 at 21:38:09 UTC, ketmar wrote:
>> H. S. Teoh wrote:
>>
>>> On Mon, Feb 26, 2018 at 10:12:25PM +0200, ketmar via Digitalmars-d wrote:
[...]

When looking at the problem of compilation times I think: Wouldn't it speed up the development process, if spiting your code in modules would automatically results in creating small libs which are - if possible - compiled only once?

The idea of using a caching mechanism, is an other general way not to compile the same over and over again. Part of the discussion is here: https://github.com/dlang/dmd/pull/7239#issuecomment-340256110

On Tuesday, 27 February 2018 at 09:25:57 UTC, Martin Tschierschke wrote:
> On Tuesday, 27 February 2018 at 08:49:15 UTC, Stefan Koch wrote:
>> On Monday, 26 February 2018 at 21:38:09 UTC, ketmar wrote:
>>> H. S. Teoh wrote:
>>>
>>>> On Mon, Feb 26, 2018 at 10:12:25PM +0200, ketmar via Digitalmars-d wrote:
> [...]
>
> When looking at the problem of compilation times I think: Wouldn't it speed up the development process, if spiting your code in modules would automatically results in creating small libs which are - if possible - compiled only once?
>
> The idea of using a caching mechanism, is an other general way not to compile the same over and over again. Part of the discussion is here: https://github.com/dlang/dmd/pull/7239#issuecomment-340256110

It's more complicate then that.
The problem with caching is dependency analysis which is pretty difficult with templates in the mix.

Martin Tschierschke wrote:

> On Tuesday, 27 February 2018 at 08:49:15 UTC, Stefan Koch wrote:
>> On Monday, 26 February 2018 at 21:38:09 UTC, ketmar wrote:
>>> H. S. Teoh wrote:
>>>
>>>> On Mon, Feb 26, 2018 at 10:12:25PM +0200, ketmar via Digitalmars-d wrote:
> [...]
>
> When looking at the problem of compilation times I think: Wouldn't it speed up the development process, if spiting your code in modules would automatically results in creating small libs which are - if possible - compiled only once?
>
> The idea of using a caching mechanism, is an other general way not to compile the same over and over again. Part of the discussion is here: https://github.com/dlang/dmd/pull/7239#issuecomment-340256110

basically, compilation of a code without templates is FAST. 500+ KB of source almost without templates often compiles in less than a second (on not-so-bleeding-edge i3, not even i7).

but throw templates in a mix, and BOOM! coffee and cigarettes.

On Tuesday, 27 February 2018 at 13:35:14 UTC, ketmar wrote:
> Martin Tschierschke wrote:
>
>> On Tuesday, 27 February 2018 at 08:49:15 UTC, Stefan Koch wrote:
>>> On Monday, 26 February 2018 at 21:38:09 UTC, ketmar wrote:
>>>> H. S. Teoh wrote:
>>>>
>>>>> On Mon, Feb 26, 2018 at 10:12:25PM +0200, ketmar via Digitalmars-d wrote:
>> [...]
>>
>> When looking at the problem of compilation times I think: Wouldn't it speed up the development process, if spiting your code in modules would automatically results in creating small libs which are - if possible - compiled only once?
>>
>> The idea of using a caching mechanism, is an other general way not to compile the same over and over again. Part of the discussion is here: https://github.com/dlang/dmd/pull/7239#issuecomment-340256110
>
> basically, compilation of a code without templates is FAST. 500+ KB of source almost without templates often compiles in less than a second (on not-so-bleeding-edge i3, not even i7).
>
> but throw templates in a mix, and BOOM! coffee and cigarettes.

My negative experience was, when using ctRegex and normal regex.
But it was no problem to separate the functions using regex in a lib and compile
them separately. (app saving 3 seconds)

The same approach was working with .dt (diet template in vibe.d) and the function(s) instantiating it, put both together in an own lib. And define it as a local external dependency. In the moment I am thinking about a way to do this automatically.
So that every new build of my vibe.d app, only needs to compile the changes.

(p.s. I am aware of this: https://github.com/rejectedsoftware/diet-ng#experimental-html-template-caching)

Martin Tschierschke wrote:

>> basically, compilation of a code without templates is FAST. 500+ KB of source almost without templates often compiles in less than a second (on not-so-bleeding-edge i3, not even i7).
>>
>> but throw templates in a mix, and BOOM! coffee and cigarettes.
>
> My negative experience was, when using ctRegex and normal regex.
> But it was no problem to separate the functions using regex in a lib and compile
> them separately. (app saving 3 seconds)

you happened to hit another issue, yeah: slow CTFE enigne. that should be improved too. ;-)