#Type checking optimization

14 messages · Page 1 of 1 (latest)

south schooner
#

After having issues with typescript crashing quite often inside vscode, I wanted to find out how I can optimize my types and make them simpler. After watching Matt Pocock's & Aleksandra Sikora video (https://www.youtube.com/watch?v=ZL3z1oBZntk), a few of the main points that were talked about, was lowering instantiations / better caching and how to achieve that.

Now a few day later, I have managed to drastically lower instantiations of my somewhat poorly implemented (typing wise) typesafe api router. To talk numbers: Instantiations: 1.85m arrow 1.2m and different caches would vary in size during optimizing and cleaning up but end up around the same size.

My main problem is that my expectation were not met at all. After a significant 35% reduction of instantiations I see no meaningful performance gains. Around 0.2-0.3s from a total of 6.5-7 seconds, and that's a huge maybe because the total time would vary a lot (probably due to the nature of JS and my 700€ laptop).

So my question, to anyone who can answer, am I blind to something obvious or am I missing something completely? If you want me to share my code/types just tell me and I'll link my repo.

Side note: On the left of the image is the optimized version and on the right one the unoptimized.

#

Also, forgot my tsconf:

#
        "extends": "astro/tsconfigs/strict",
        "compilerOptions": {
                "noErrorTruncation": true,
                "strict": true,
                "allowUnusedLabels": true,
                "diagnostics": true,
                "extendedDiagnostics": true,
                "noImplicitAny": true,
                "skipLibCheck": true,
                "skipDefaultLibCheck": true,
                "alwaysStrict": true,
                "noUncheckedIndexedAccess": false,
                "noEmit": true,
                "jsx": "preserve",
                "jsxImportSource": "solid-js",
                "types": ["@types/node", "@cloudflare/workers-types"]
        }
}```
#

Also, forgot to mention that using --generateTrace was useful to identify certain hotspots of the program and type checking, but after optimizations, they didn't get much better.

shadow locust
#

I didn't watch the video but the biggest cause of lag in my experience is big discriminated unions.

#

in my project i had to just give up type safety for some contexts, since the performance hit of adding a bunch of discriminated unions was blowing everything else up

south schooner
#

The only relatively big union that I have is the one to accurately return the response type of the API call, based on a generic keyof of all the available endpoint name. I guess, I could split the unions based on a general level so that I have multiple smaller unions per general route, instead of a union of the whole router.
Though I somewhat doubt that this would help a lot, I'll try it out. But it is a bit silly to write your code around efficient type checking, when this should be trivial... I am still waiting for a type checker in Rust 😴

shadow locust
#

well as a quick test just have the response type be string and then test perf

native sentinel
#

Probably won't have time to look at it until this weekend... but I'm interested, please share the repo :)

south schooner
# shadow locust well as a quick test just have the response type be `string` and then test perf

By simply returning a string I would have to spend quite a bit of time refactoring large amounts of code so that the compiler is happy and no error is found.

A few days past, and I did try to make the API to be accessed in a manner of something like that: API[BaseRoute][SubRoute]. Unfortunately it did not work due to 2 reasons: 1) After making it to work, the type checker would really struggle to check and autocomplete, 2) The second accessor SubRoute would have to be a single source of truth, as it would straight up refuse to do so otherwise, and therefore typing it was a hell. I guess the limit=2 for such a thing.

south schooner
# native sentinel Probably won't have time to look at it until this weekend... but I'm interested,...

If you'd like to have a look that would be great. My repo is this (https://github.com/Kostas-Xafis/byzantini-website). If you plan on cloning, go to the commit on Jan 3 because I changed some stuff and as a result worsening a bit the instantiations. To help you go right ahead, the main 2 points of intereset would be the /types folder and the /lib/routes. To quickly avoid you from confusion. I have named them as .client.ts and .server.ts so that I'd avoid any server only code, leak in to the client, while also preserving type safety and use of the routes in the client.

south schooner
#

Closing this, since I found the reason of the type checker slowdown.

#

!resolved

shadow locust
#

what was it