The worst Phobos template (in binderoo)

Hi Guys, I recently had a closer look at the templates that cost the most time to instantiate in the frontend. and there is one clear winner. FullyQualified name from std.traits. It takes a whooping 500 milliseconds(on my test-case) for it's semantic phase. this is because this template is recursive and because it instantiates std.format.format which is on fourth place for slow templates. The functionality can be implemented with a __trait and that implementation would be 500 times faster. I am going to submit a PR soon. However I cannot guarantee that the newly introduces trait work the same in all cases. As templates can behave surprisingly sometimes. I would like to see users of fullyQualifiedName because apart from binderoo code which seems to work, I have none.

On Wednesday, 14 September 2016 at 20:24:13 UTC, Stefan Koch wrote: > It takes a whooping 500 milliseconds Ahm... I misread my performance graph it's 138ms for the first instanciation. and around 5ms for every following one. the total time spent on it was 500ms

September 14, 2016

Re: The worst Phobos template (in binderoo)

Posted by Andrei Alexandrescu
in reply to Stefan Koch

Permalink

Andrei Alexandrescu

Posted in reply to Stefan Koch

Permalink

On 09/14/2016 04:52 PM, Stefan Koch wrote:
> On Wednesday, 14 September 2016 at 20:24:13 UTC, Stefan Koch wrote:
>> It takes a whooping 500 milliseconds
> Ahm... I misread my performance graph
> it's 138ms for the first instanciation.
> and around 5ms for every following one.
> the total time spent on it was 500ms

(Disclaimer: I didn't run any speed tests.) By looking at the definition of fullyQualifiedName it seems to me we can go a long way with traditional optimization techniques. For example consider:

string result = join(
  map!(a => format("%s%s", a[0], a[1]))(
    zip([staticMap!(storageClassesString, parameterStC)],
      [staticMap!(fullyQualifiedName, parameters)])),

This is neat, and it's neat squared because it works during compilation, but at some point if the resulting code runs slowly, there's no shame in applying old school optimization. Instead of join/map a simple loop should suffice; no need to use format with "%s%s" over simple concatenation; array zipping may be done with simple loops too.

Same a few lines below - just replace return format("%s%s%s%s%s%s%s%s", ...) with simple concatenation. Same goes with format("shared(%s)", ...), format("%s(%s)", ...) etc. In casual runtime code such code is totally fine, but in library code we'd do good to eliminate the use of format (which is a mini-interpreter) if speed considerations tell us to.

The unittests seem excessive too. Yes, there is such a thing as too much of a good thing. And use a lot of format during compilation as well :o). In unittests, a bunch of static asserts may be replaced with regular asserts.

Andrei

On Wednesday, 14 September 2016 at 21:06:10 UTC, Andrei Alexandrescu wrote: > On 09/14/2016 04:52 PM, Stefan Koch wrote: >> [...] > > (Disclaimer: I didn't run any speed tests.) By looking at the definition of fullyQualifiedName it seems to me we can go a long way with traditional optimization techniques. For example consider: > > [...] staticMap is number 3 in the top-slow-templates list. And the code inside it really does not matter so much. What matters is recursive instanciation. the evaluation of the function is fast in comparison to the time the template-subsystem takes. I believe this cannot be fixed by changing a library solution.

On Wednesday, 14 September 2016 at 20:24:13 UTC, Stefan Koch wrote: > I would like to see users of fullyQualifiedName because apart from binderoo code which seems to work, I have none. I've had to use fullyQualifiedName in some string mixins. Take a look at https://github.com/BlackEdder/painlessjson/blob/9f9b94b3a47ada4ffdea16ef5dc5476c74cb9a06/source/painlessjson/painlessjson.d#L415. I also recommend using GitHub search to find other examples.

On Wednesday, 14 September 2016 at 22:48:29 UTC, Pierre Krafft wrote: > I've had to use fullyQualifiedName in some string mixins. Unless there is more to the example than what meets the eye, "had to" isn't quite true, and even with the `import moduleName!…` hack, your code is still unnecessarily restrictive. Just use ` ~ "fromJSON!(typeof(t." ~ name ~ "))…"` instead. I'd really like to know where the notion that stringifying symbols for mixin code generation is a viable choice comes from. People seem to try with an irritating regularity, only to inevitably discover that it doesn't actually work some time later. That one can get dangerously close now that we have `moduleName` doesn't exactly help either. — David

On Wednesday, 14 September 2016 at 20:28:13 UTC, Stefan Koch wrote: > On Wednesday, 14 September 2016 at 20:24:13 UTC, Stefan Koch wrote: > >> I would like to see users of fullyQualifiedName because apart from binderoo code which seems to work, I have none. > > That was supposed to say : I would like to see [test cases from] users of fullyQulifiedName. I wrote a type overload of it long time ago to be used in vibe.d REST interface generator - combined with static imports it ensured symbol hygienne. Though it possible current implementation doesn't use it anymore. Intended semantics was to be as close to this as possible: mixin("alias T2 = " ~ fqn!T); static assert(is(T2 == T)); In that sense builtin trait could be a better option.

On Thursday, 15 September 2016 at 06:08:33 UTC, Dicebot wrote: > > mixin("alias T2 = " ~ fqn!T); > static assert(is(T2 == T)); > > In that sense builtin trait could be a better option. Yes a builtin trait is the better option. I made a youtube video about that. Showing you how bad FullyQualifiedName is and how much better a trait is. https://www.youtube.com/watch?v=l1Ph3Nn0en0

Forums