join() in CTFE very low performance

[realhet]

On Saturday, 4 January 2025 at 15:34:27 UTC, monkyyy wrote:
> On Saturday, 4 January 2025 at 13:56:47 UTC, realhet wrote:

> Id check that it is a string and not some sort of lazy wrapper 
> type doing worse of both world things; I usually use `enum 
> string[]` for mixin-y things when possible, idk what style your 
> doing and the q{} may have some extra logic.

That style indeed makes no sense on text mode.
Here's what it looks in graphic mode: https://youtu.be/8brvCoMaWyQ

At the end of the video I've tried out 4 versions.

The first one is super fast (--ftime-trace) -> It puts the table 
in the global scope, then the mixin just inject a simple 
transformation expression on it so the string[][] table is 
transformed into a Struct[] in compile time.

But the big difference is that the later 3 versions are putting 
data onto the string surface of the mixin.  They use the 
universal std text() template function to do that.  And that is 
working extremely slow inside the context of the Compile Time.

When I look at the --ftime-trace, I see text() formatValue() 
everywhere. It feels like the CT version of text() does 
everything by the limited but safe tools of CT environment, 
something like CtRegexpr. It looks like they discover their 
parameter signatures every time from zero.  They can't remember 
that they already compiled text(string[]) formatValue(string), 
etc.
Both of those CT things (text, format, regexpr) are awesome but I 
guess I should avoid them while using string mixins.


Maybe those 'lazy wrappers' you mentioned can be inside text()?
My wrapper struct named with a chinese character is rellly 
simple: struct S{ string[][] rows; } first member is the table 
rows with the cells.

q{}  always worked perfectly.  I have no fear of that.

Also no problems with the new goodies: iq{} and ${}   I'm testing 
them like crazy, I really like them.

Only the very complex stuff works weird in CT -> text, format...