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.
![](https://i.ibb.co/bJsshPZ/without-ctfe.png)
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