Repository navigation
Design Meeting Notes, 8/25/2021 #45577
Description
Activity
Daniel Rosenwasser (@DanielRosenwasser) have you tried to solve the stack overflow problem using trampoline technique?
const trampoline = f => (...args) => { let result = f do { result = result(...args) } while (typeof result === 'function') return result } const factorial = n => factorialAcc(1n, n) const factorialAcc = (acc, n) => { if (n <= 1) { return acc } return () => factorialAcc(acc * BigInt(n), n - 1) } const factorialT = trampoline(factorial) console.log(factorialT(300))
Performance tests for the large call stack case:
No trampoline test for factorial(2500): 8.612300038337708 ms No trampoline test for factorial(2500): 8.430999994277954 ms No trampoline test for factorial(2500): 8.416900038719177 ms No trampoline test for factorial(2500): 8.343400001525879 ms No trampoline test for factorial(2500): 8.81769996881485 ms Trampoline test for factorial(2500): 6.159500002861023 ms Trampoline test for factorial(2500): 6.034699976444244 ms Trampoline test for factorial(2500): 6.161700010299683 ms Trampoline test for factorial(2500): 5.963100016117096 ms Trampoline test for factorial(2500): 5.686100006103516 ms
Performance tests for the small call stack case:
No trampoline test for factorial(100): 0.05640000104904175 ms No trampoline test for factorial(100): 0.0591999888420105 ms No trampoline test for factorial(100): 0.07770001888275146 ms No trampoline test for factorial(100): 0.06279999017715454 ms No trampoline test for factorial(100): 0.05779999494552612 ms Trampoline test for factorial(100): 0.08009999990463257 ms Trampoline test for factorial(100): 0.08600002527236938 ms Trampoline test for factorial(100): 0.0835999846458435 ms Trampoline test for factorial(100): 0.0821000337600708 ms Trampoline test for factorial(100): 0.08160001039505005 ms
I didn't capture it in the notes but
- We raised generators as an option, and the overhead of generators (both down-leveled for ES5, and maintained for ES2015 targets) had a considerable performance hit.
- Re-writing with a manual trampoline (as Wesley Wigham (@weswigham) did for other constructs like checking binary operands) is possible, but makes the code harder to maintain and update in our opinion. I don't know if our trampolining works similarly to what you have up there.
Wesley can correct me if I got any of the details wrong.
I mean, our existing trampolines function as state machines rather than recreating closures all the time, but yes.
Reacted by Daniel Rosenwasser and ExE Boss
The
AwaitedType inlib.d.ts#45350
When we introduced
awaitinto TypeScript, we added some logic to recursively unwrap a type.At the time, we had no recursion mechanism within the type system.
First we started out with an
awaitedtype operator.Problem: if you have generics, you end up with higher-order type operators.
awaited Tis not necessarily assignable toT(nor vice versa).Had ideas for a top-level type alias...
And that's what we do here, but right now are only introducing the alias to be used in
lib.d.ts.awaitoperator does.Preserves the incorrect behavior to avoid errors on
awaited T -> Tin async functions, but better-modelslib.d.ts.Ideally, other overloads take care of the breaks.
Does this break existing code?
Having
Awaitedmakes sense in general.Worth thinking about whether users will be able to understand how to use this.
Should we get rid of the other overloads?
Conclusions
await?--noErasingImportedNames#44619
isolatedModules, it will warn you that some compiler won't know how to drop types.Svelte.
Layout.Vue
<script setup>.noErasingImportedNameshard to parse.preserveValueImports"importsNotUsedAsValues": "preserve"😢Stack Overflow on Type Instantiation
#45576
try/catch.try/catchat the top ofinstantiateType?