René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Performance issue checking IndexedAccess rest parameter that resolves to large union of tuples","articleBody":"\u003c!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. --\u003e\r\n**TypeScript Version:**  3.1.0-dev.20180829, master\r\n\r\n\u003c!-- Search terms you tried before logging this (so others can find this issue more easily) --\u003e\r\n**Search Terms:** rest, parameters, union, tuple, IndexedAccess, \r\n\r\nI realize this may be firmly in the camp of \"doctor, it hurts when I do this\", but thought I'd still file :)\r\n\r\nI ran into this when using a union of tuples in place of overloading, not realizing it wasn't really supposed to be working until #26676. Since the tuples came from the values of an interface, I believe the indirect indexed access was allowing it to still pass since it would fall back to structural checking against `any[]`.\r\n\r\nWith #26676 landed it's still an issue, though.\r\n\r\n**Code**\r\nThis was from an attempt to type the Chrome debugger rpc protocol using tuples to represent that some commands need no parameters, some need one, and some can optionally have one. I'll link to the type files since they're large, but I can provide them elsewhere if needed: [`ChromeDevTools/devtools-protocol/pull/113/protocol-mapping.d.ts`](https://github.com/ChromeDevTools/devtools-protocol/blob/68f219dd201c2eb571d31d89a95e8c60c05bd152/types/protocol-mapping.d.ts#L459-L3267), and the types referenced in that file are found in [`protocol.d.ts`](https://github.com/ChromeDevTools/devtools-protocol/blob/68f219dd201c2eb571d31d89a95e8c60c05bd152/types/protocol.d.ts). All the types end up relatively shallow and without cycles.\r\n\r\nPoor performance can be triggered with\r\n\r\n```ts\r\nimport ProtocolMapping  from './protocol-mapping';\r\ntype Commands = ProtocolMapping.Commands;\r\n\r\nfunction sendCommand\u003cC extends keyof Commands\u003e(method: C, ...params: Commands[C]['paramsType']) {}\r\n```\r\n\r\nThis takes ~6 seconds to check with `tsc --strict` on my machine, with about 3.5 seconds attributable to `checkParameter()` of `...params`. More crucially it adds a similar amount of time to tsserver responses, and the work doesn't seem to be cached, so it re-runs on every intellisense completion. \r\n\r\nOn the other hand, the not quite equivalent\r\n\r\n```ts\r\nfunction sendCommand\u003cC extends keyof Commands\u003e(method: C, ...params: Commands[keyof Commands]['paramsType']) {}\r\n```\r\n\r\ntakes about 2 seconds (with about 300 ms of that attributable to `checkParameter` of `...params`).\r\n\r\nThe difference appears to come down to when the checker realizes the type is a union of tuples. The fast version does appear to end up checking each tuple for structural similarity to `any[]`, but it does so for each tuple in the union individually, which is relatively fast.\r\n\r\nThe slow version seems to instead get deep enough that it ends up taking the union of each property across the tuples, then compares each of those against the properties of `any[]`. Since in this example basically each tuple ends up with a unique typeArgument, I assume the structural comparison against these unions for each property is what's taking the bulk of this time. The profile is mostly stuck in `getPropertiesOfUnionOrIntersectionType` down to `createUnionOrIntersectionProperty` and then splitting up into many nested `isRelatedTo` calls.\r\n\r\nHopefully the slow case could be made to function more like the fast case, but it also seems like a shortcut is possible since the tuples are never used for anything but rest parameters (so memoized type info is never used again) and as soon as `getApparentType()` is called with `Commands[C]['paramsType']`, the type then becomes a union of objects with `ObjectFlags.Tuple`, which could be used for an even quicker test.\r\n\r\nTo check, I added a super hacky `isUnionOfTuples` method and the time spent dropped to essentially nothing. I might be missing the corner cases here (or that my case is a special case of some tricky general issue), but if rest parameters for overloading becomes popular, it seems like a fast path for when the apparent type of `source` is a union of tuples and `target === anyArrayType` could be generally useful without much cost.","author":{"url":"https://github.com/brendankenny","@type":"Person","name":"brendankenny"},"datePublished":"2018-08-30T00:17:33.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":5},"url":"https://github.com/26756/TypeScript/issues/26756"}