Case of extremely slow type checking

[agj]

I have a query pattern that degrades tsc type checking performance to an outsized degree. It involves a nested query in selectFrom, and a simple where clause.

This is my most minimal reproduction:

const demoQuery = (db: Kysely<DB>) =>
  db
    .selectFrom((eb) =>
      eb
        .selectFrom("my_table")
        // Removing this `where` makes a dramatic difference in compilation time.
        .where((eb2) => eb2("my_table.id", "in", [1, 2, 3]))
        .selectAll()
        .as("test")
    )
    .selectAll();

With the where line indicated by the comment, running tsc --diagnostics --noEmit takes about 30 seconds, whereas after removing it it takes about a second.

TypeScript diagnostics with where:

Files:              435
Lines:           119235
Identifiers:     112580
Symbols:         258239
Types:           185820
Instantiations: 4743126
Memory used:    581215K
I/O read:         0.19s
I/O write:        0.00s
Parse time:       0.87s
Bind time:        0.27s
Check time:      30.30s
Emit time:        0.00s
Total time:      31.44s

TypeScript diagnostics WITHOUT where:

Files:              435
Lines:           119235
Identifiers:     112577
Symbols:          76912
Types:             2539
Instantiations:   10897
Memory used:    133318K
I/O read:         0.04s
I/O write:        0.00s
Parse time:       0.78s
Bind time:        0.23s
Check time:       0.25s
Emit time:        0.00s
Total time:       1.26s

My DB has a large number of tables, so I'm sure that's part of the issue, but I never had this problem until I added this particular pathological query.

I'm using:

• kysely v0.27.2
• typescript v5.3.3
• Node v21.6.1

---

Edit: Here's a Github gist with all of the files needed to reproduce this issue.

[agj]

Forgot to add that I'm immensely appreciative of the work done on Kysely. It's a great tool that lets us work with our database without fear. 🙏

[igalklebanov]

Hey 👋

Does this improve performance?

const demoQuery = (db: Kysely<DB>) =>
  db
    .selectFrom((eb) =>
      eb
        .selectFrom("my_table")
        .where("my_table.id", "in", [1, 2, 3])
        .selectAll()
        .as("test")
    )
    .selectAll();

[agj]

Hi! I'm away from my computer, as I'm on vacation right now, but as soon as I'm back I'll give it a try!

[agj]

@igalklebanov It did improve it quite a bit! But it's still not great…

Files:              435
Lines:           119236
Identifiers:     112578
Symbols:         246727
Types:             7593
Instantiations: 1355207
Memory used:    212941K
I/O read:         0.05s
I/O write:        0.00s
Parse time:       0.69s
Bind time:        0.30s
Check time:      11.30s
Emit time:        0.00s
Total time:      12.29s

[kevin-johne]

Hello there, and thank you for the amazing project, I introduced the typesafe query builder into our project which containes alot of tables. I wonder if Kysely is made for a scale of 100s and 100s of tables with 100s of complex queries.

Without Kyseley type checking is around 8 seconds, after starting generating the types of our db and only include ~100tables and written complex queries which use the expression builder to compose sub queries with joints. The query results are efficient and build for purpose And I start already plunching in the 60 seconds type checking.
This makes the intellisense so slow and with delay that I'm not able to write more queries.

If this performance is odd I will go deeper into stats and post them here.
Thank you

TypeScript version 5.1.6

[igalklebanov]

I'd strongly consider splitting data access to several Kysely instances with their own limited view of the world, if possible.
I believe kysely-codegen has a filtering mechanism, should come in handy.

Kysely is built around, for the most part, string literal type comparisons. The more unique column and table names in DB interface, the slower type-checking gets and harder language server works.

[kevin-johne]

thank you for your quick reply, I will give this a try.

[thelinuxlich]

would a split into multiple schemas on the same interface, differentiated by the prefix, alleviate the performance issue?

[koskimas]

I'm not able to reproduce this. Any chance to get a full reproduction? A complete project I can run and profile?

[agj]

Yeah, sure. Here's a Github gist with the relevant files, including an anonymized version of the database types.

[imwexpex]

A big issue on our project as well. Please let me know if there is anything I could assist with.