The New Fundraising Campaign

[H. S. Teoh]

On Wed, Jan 02, 2019 at 02:49:19PM +0000, Adam D. Ruppe via Digitalmars-d-announce wrote:
> On Wednesday, 2 January 2019 at 11:11:31 UTC, Stefan Koch wrote:
> > On Wednesday, 2 January 2019 at 10:16:11 UTC, Martin Tschierschke wrote:
> > > 
> > > I would love to have a campaign to increase compilation speed for
> > > std.regex and std.format...
> > 
> > You could defer the generation of utf-tables to runtime, which
> > should yield some improvement. But I'll measure the reasons for
> > slowness again and post em.
> 
> We should just generate them in a helper program in the Phobos
> makefile.
> 
> Yeah, it is kinda embarrassing that we are using a C technique instead
> of D CTFE. But whatever, it is less embarrassing than these awful
> compile times in user code.

I don't perceive it as embarrassing at all. In my recent projects I've
resorted quite often to helper D programs that generate D code from
external input. It *could* be done via string imports, CTFE, and string
mixins, but that makes (1) compilation dog-slow, (2) the actual
generated code existing only transiently inside the compiler, which (3)
makes it hard to debug (esp. if the codegen isn't your own code) - (4)
any compile errors are by necessity obscure because there isn't a
concrete file and line number to refer to; to get to the locus of the
problem further effort is required to extract the generated code string
(after figuring out which string is the relevant one!) and then
dereference the line number.

Doing codegen as a separate step is so much better: (1) you get to see
the actual generated code, (2) learn how it works / self-correct by
studying how your (possibly incorrect) input / usage changes the code,
(3) have an actual file/line number that can be looked up at your
leisure, and (4) edit the generated code by hand if it really comes down
to that.

(Of course, this requires that you use a sane build system that doesn't
come with crippling operating assumptions or other arbitrary
restrictions that make this additional codegen step hard / unreliable /
impossible.)

None of this means that string mixins are no good... in fact I use them
quite a bit myself too.  But they are more suitable for small
code snippets to grease the main code, not for large scale, bulk codegen
from external data sources. I'd argue that std.uni tables really belong
to the latter category. In fact they *are* mostly generated statically,
but then they get wrapped inside templates, which arguably could be
avoided esp. since the compiler quickly becomes dog-slow with too many
templates.


T

-- 
Questions are the beginning of intelligence, but the fear of God is the beginning of wisdom.