Getting the names of all the top-level functions in module
Stefan Koch
uplink.coder at googlemail.com
Tue Sep 21 23:27:49 UTC 2021
On Tuesday, 21 September 2021 at 22:53:26 UTC, Stefan Koch wrote:
> On Tuesday, 21 September 2021 at 17:15:23 UTC, Stefan Koch
> wrote:
>> On Tuesday, 21 September 2021 at 15:18:01 UTC, Stefan Koch
>> wrote:
>>> On Tuesday, 21 September 2021 at 15:07:35 UTC, Adam D Ruppe
>>> wrote:
>>>> Here's one with param names:
>>>>
>>>> ----
>>>>
>>
>> I've done a little benchmark the core.reflect version vs the
>> template version.
>>
> Scratch that.
> It turns out I should have tested the output.
>
>
> The simple truth of this is that the CTFE concatenation is the
> weak link here.
>
So if ctfe is the limiting factor how does the graph look when
CTFE is taken out of the picture.

That's how.
core.reflect looks linear
while the template shows signs of becoming superlinear.
However I cannot test it on bigger N because there is a
restriction to how many synthetic symbol-names the compiler can
create ...
```d
// Perturb the name mangling so that the
symbols can co-exist
// instead of colliding
s.localNum =
cast(ushort)(originalSymbol.localNum + 1);
assert(s.localNum); // 65535 should
be enough for anyone
```
ah well :-)
It should be noted that core.reflect can be used with much higher
N because it doesn't create symbols in that way.
More information about the Digitalmars-d
mailing list