-
Notifications
You must be signed in to change notification settings - Fork 48
Description
I'm not sure if this is in ts-simple-type or in lit-analyzer, but there's a huge performance bottleneck somewhere i struggled to track down fully myself.
Basically, when we visit a html assignment, we extract the types of the left and right:
| const { typeA, typeB } = extractBindingTypes(assignment, context); |
Within extractBindingTypes, we then compute the right hand side's "simple type":
lit-analyzer/packages/lit-analyzer/src/rules/util/type/extract-binding-types.ts
Lines 36 to 39 in 950d0e3
| let typeB = (() => { | |
| const type = isSimpleType(typeBInferred) ? typeBInferred : toSimpleType(typeBInferred, checker); | |
| return shouldRelaxTypeB ? relaxType(type) : type; | |
| })(); |
This is all fine, but we hit a strange performance issue when we have something like this:
_onKeyUp(ev: KeyboardEvent): void {
// ...
}
render() {
return html`<input @keyup=${this._onKeyUp}>`;
}What this results in is ts-simple-type recursively trying to "resolve" the types and turn them into "simple types". Again, fine.
Until we hit the KeyboardEvent type and try resolve it.. we then hit this:
which as you can see references Window. From then on, it often (almost always) takes 500ms+ just to parse whatever "Window" is, jumping around all over the place...
this results in the majority of my analysis CPU time being spent on resolving types we ultimately don't care about (~9 seconds in my case). im not sure how you'd improve this other than by having a recursion limit or something...