Is glint v2 supposed to be slower?

[ijlee2]

In ember-container-query, ember-intl, embroider-css-modules, and a production app, I'm seeing that lint:types takes 20-55% more time to run. In the case of the production app, I had to increase the memory in CI to fix the JavaScript heap out of memory error.

> time pnpm lint:types

# Production app (before)
pnpm lint:types  22.94s user 2.27s system 170% cpu 14.814 total
pnpm lint:types  23.06s user 2.27s system 172% cpu 14.666 total
pnpm lint:types  22.91s user 2.36s system 168% cpu 15.020 total

# Production app (after)
pnpm lint:types  35.35s user 2.41s system 158% cpu 23.783 total
pnpm lint:types  33.42s user 2.42s system 158% cpu 22.678 total
pnpm lint:types  33.42s user 2.44s system 158% cpu 22.650 total

The migration went smoothly (great job to everyone), but I still felt a little disappointed, because I had thought that using *.{gjs,gts} would give us a performance boost over using *.hbs. Is the memory consumption/runtime expected to increase? Did I perhaps not configure the projects correctly (see the 3rd commits in the links above)?

These are the dependencies that I had/have:

Before:

• @glint/core@1.5.2
• @glint/environment-ember-loose@1.5.2
• @glint/environment-ember-template-imports@1.5.2
• @glint/template@1.5.2

After:

• @glint/ember-tsc@1.0.7
• @glint/template@1.7.2

[NullVoxPopuli]

We have way more accuracy and features than we did before via using volar, so i can't say i'm completely surprised, but a generated profile would help us find slowness if you want to provide one of those

[ijlee2]

a generated profile

Can you elaborate for me how to do this?

I used pnpm.overrides to install a particular version of @glint/template (all other factors remained the same) to check when things became slow.

# @glint/template@1.6.2
pnpm lint:types  24.63s user 1.85s system 173% cpu 15.247 total
pnpm lint:types  24.93s user 1.84s system 173% cpu 15.399 total
pnpm lint:types  24.97s user 1.88s system 172% cpu 15.596 total

# @glint/template@1.7.0
pnpm lint:types  34.68s user 2.55s system 152% cpu 24.462 total
pnpm lint:types  35.41s user 2.54s system 154% cpu 24.560 total
pnpm lint:types  35.28s user 2.52s system 155% cpu 24.384 total

# @glint/template@1.7.1
pnpm lint:types  34.31s user 2.60s system 156% cpu 23.539 total
pnpm lint:types  34.55s user 2.49s system 156% cpu 23.672 total
pnpm lint:types  34.48s user 2.50s system 156% cpu 23.574 total

From the output above, I think #1005 is the reason and, in particular, due to the use of Lookup in packages/template/-private/dsl/types.d.ts.

I'm currently trying to see how we can optimize the calculation, but don't understand from the PR what you had wanted Lookup to do. Here are some input-output pairs that I found using TypeScript's Playground:

type Example01 = Lookup<HTMLElement> // "HTMLHeadElement" | "HTMLElement" | "HTMLPictureElement" | "HTMLSpanElement"
type Example02 = Lookup<HTMLDivElement> // "HTMLTableCaptionElement" | "HTMLDivElement" | "HTMLHeadingElement" | "HTMLParagraphElement"
type Example03 = Lookup<HTMLInputElement> // "HTMLInputElement"
type Example04 = Lookup<HTMLTextAreaElement> // "HTMLTextAreaElement"
type Example05 = Lookup<HTMLLIElement> // "HTMLLIElement"

type Example11 = Lookup<SVGElement> // "SVGDescElement" | "SVGMetadataElement" | "SVGTitleElement" | "SVGElement"
type Example12 = Lookup<SVGTextElement> // "SVGTextElement" | "SVGTSpanElement"

Can you explain to me why the inputs HTMLElement, HTMLDivElement, SVGElement, and SVGTextElement result in the output of a union type, which seemingly doesn't have anything to do with the input (e.g. why look at "HTMLTableCaptionElement", "HTMLHeadingElement", and "HTMLParagraphElement" when the input is HTMLDivElement)?

[NullVoxPopuli]

nice find!

We had to removing the branding because elements were no longer compareable vie their inhertence chain, so modifiers and such that specified a generic HTMLElement were no longer a sufficient superclass of HTMLDivElement, for example.

Can you explain to me why the inputs

the overall goal of the Lookup is to find the attributes for a particular element type.
So, this happens a in a couple steps,

1. Get the "Key" for the attributes maps (the string) -- this is a union, because all those elements have the same attribute lists
2. get the attributes for the key provided by lookup.

The string-type<->Attributes map is defined in elements.d.ts, GlintHtmlElementAttributesMap

In #1016, I'm also exploring changing the emitted intermediate representation so that I can use the element name for the lookup instead of the type, since type-lookups sort of don't exist in TS

[NullVoxPopuli]

hm, no we can't get away from type->attributes lookup, because in-component attributes need it based on the signature's element type