Minor performance issue when using HTMLElementTagNameMap

[jasonlyu123]

🔎 Search Terms

HTMLElementTagNameMap
performance

🕗 Version & Regression Information

• This changed between versions 5.9.3 and 6.0.2

⏯ Playground Link

https://www.typescriptlang.org/play/?#code/GYVwdgxgLglg9mABAWwIYAcCiAbAps3MKAHgGlFcAPKQgEwGdEBrXATzmEQAkAVAWQAyOfISg9UAcwByqAnwwA+ABS48BIgC5EpAJRbeg4erGSZcjAG1SAXQBQoSLAQoMR0WQrU6jFu04BlADUAcTcicWlZXHl0RGVVEU1tPUQg0LVRCLNoyxt7cGh4JDQsDKIVMqgtVDBWFIMhSsQAb1tERAAnXCgQDqRaOAgQYwA6CC7UGjCoCsSoHQBuWwBfW1tUQoQlEumlAHJaGAA3PZ1FtYdNpA2nMFn9fka5nRaV9qA

💻 Code

function mapElement<K extends keyof HTMLElementTagNameMap>(element: K): HTMLElementTagNameMap[K]
function mapElement<K extends keyof SVGElementTagNameMap >(element: K): SVGElementTagNameMap[K]
function mapElement(element: any): HTMLElement {
  return document.createElement(element);
}

action(mapElement('div'));

function action(ele: HTMLElement) {
}  

🙁 Actual behavior

The type check for this specific overload is slower in TypeScript 6.0, but still bearable (under 50ms on a modern PC). From the flame graph, it seems like the hot path is

https://github.com/microsoft/TypeScript/blob/7b8cb3bdf82f400642b73173f941335775d6f730/src/compiler/checker.ts#L25342

This also seems to happen in TypeScript 7, but I can't reliably reproduce it. It doesn't happen on my Windows machine, but on my Linux machine.

Although this seems minor, it is a bit odd that TypeScript needed to create a union of all the HTML elements, comparing all the properties to choose an overload. If this doesn't match the merge criteria, maybe it can still be improved in TypeScript 7? Or maybe there is another way to type this function that won't trigger this?

🙂 Expected behavior

performance improvement.

Additional information about the issue

For context, this issue was found in our performance smoke test in https://github.com/sveltejs/language-tools. It consistently failed with TypeScript 6. The virtual code for the Svelte file includes a svelteHTML.mapElementTag('div') function call. The function is similar to the reproduction, just that it uses the deprecated ElementTagNameMap.

[RyanCavanaugh]

The originating commit is 9c4c377, which is just a DOM update. The checker itself did not change.

It looks like the cost to check here is O(map_entries * properties_per_element) and both of those increased a bit. I don't think there's any core defect here, it's just the cost of doing the necessary work.

[jasonlyu123]

The time indeed started to increase in 9c4c377. I wonder if it has something to do with the order of the comparison. In 837e3a1, the isInstantiation in this line is false during our test, so compareProperties is never called. But in 9c4c377, it's true. I can't retest this right now, but in my office PC(or it might have to do with the file path), the prop !== singleProp condition is never true in 5.9.3. That might also explain why it doesn't trigger in typescript-go in some environments. Also, when the problem is triggered, the id of the Symbol is 0, which sounds like it hasn't been assigned an id.

I also found another reason why our test failed. The baseline getProgram is actually faster in TypeScript 6. We use the creation time of ts.program with no project file as the baseline. The decrease meant the test is somewhat stricter. The test took longer, so I didn't notice the target time had also decreased.

At this point, I think this is more of a potential performance improvement than a problem with TypeScript 6/7. It most likely is an existing problem that was triggered by the DOM definition update.