Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

perf: use emit from swc instead of tsc #15118

Merged
merged 18 commits into from
Jul 12, 2022

Conversation

dsherret
Copy link
Member

@dsherret dsherret commented Jul 7, 2022

This change separates emitting from type checking and now only emits with swc. It also separates the emit cache from the type checking cache.

Part of #13302

Closes #14632
Closes #8706

cli/emit.rs Outdated Show resolved Hide resolved
@dsherret dsherret marked this pull request as ready for review July 11, 2022 23:21
@dsherret dsherret requested review from kitsonk and bartlomieju July 11, 2022 23:21
cli/emit.rs Show resolved Hide resolved
Copy link
Contributor

@kitsonk kitsonk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a few thoughts

cli/cache/check.rs Show resolved Hide resolved
}

impl TypeCheckCache {
pub fn new(db_file_path: &Path) -> Result<Self, AnyError> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

meta: we have never managed the sizes of caches, and having an unbounded database it raises the question of quota management and how we would manage an LRU and size constraints.

Copy link
Member Author

@dsherret dsherret Jul 12, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't think it was worth the extra complexity, but maybe it is? The previous tsbuildinfo cache was also unbounded.

I just wrote some tests for this and for the same entrypoint type checked multiple times with a unique change each time, the end result was this (the hashes don't take up a lot of room):

  • 1,000 unique type checks - 92KB (size of sqlite db)
  • 5,000 unique type checks - 316KB
  • 10,000 unique type checks - 600KB

Also, I didn't notice any slowdown in speed as the database size grew.

However, once you start type checking different root entry points, then it starts to grow a lot because it stores the tsbuildinfo as well. For example, this is with unique entrypoints:

  • 1,000 unique entry points - 6.1MB
  • 5,000 unique entry points - ~30MB
  • 10,000 unique entry points - 59.5MB

For this, I also didn't notice any slowdown as the database size grew... it remained exactly the same. SQLite seems quite fast.

I think it would be unlikely for someone to even have more than 100 root entrypoints before upgrading their CLI version. Let me know your thoughts.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I don't disagree, it was more of a meta concern that this plus other stuff likely needs better quota management.

cli/cache/check.rs Show resolved Hide resolved
cli/cache/check.rs Show resolved Hide resolved
cli/cache/common.rs Show resolved Hide resolved
/// Runs the common sqlite pragma.
pub fn run_sqlite_pragma(conn: &Connection) -> Result<(), AnyError> {
// Enable write-ahead-logging and tweak some other stuff
let initial_pragmas = "
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question: how were these determined?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's from here:

// Enable write-ahead-logging and tweak some other stuff.
let initial_pragmas = "
-- enable write-ahead-logging mode
PRAGMA journal_mode=WAL;
PRAGMA synchronous=NORMAL;
PRAGMA temp_store=memory;
PRAGMA page_size=4096;
PRAGMA mmap_size=6000000;
PRAGMA optimize;
";
conn.execute_batch(initial_pragmas)?;
conn.set_prepared_statement_cache_capacity(128);

Divy let me know about these in the last pr: #13462 (comment)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, how were they determined?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cc @littledivy -- do you know?

cli/cache/emit.rs Show resolved Hide resolved
cli/cache/emit.rs Show resolved Hide resolved
cli/tsc/compiler.d.ts Outdated Show resolved Hide resolved
return false;
}
hasher.write(specifier.as_str().as_bytes());
hasher.write(code.as_bytes());
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be better to use precomputed hashes of the code here instead of the code itself?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe. I wouldn't be surprised if retrieving and storing those hashes is slower than just doing the hash though. xxhash is very fast.

Copy link
Contributor

@kitsonk kitsonk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@kitsonk
Copy link
Contributor

kitsonk commented Jul 12, 2022

Oh, I forgot, how is the output of deno info impacted?

@dsherret
Copy link
Member Author

Oh, I forgot, how is the output of deno info impacted?

@kitsonk no, I don't believe so because only the tsbuildinfo file was moved here.

In an upcomming PR for #13302 the emit path will be removed (source will stay).

@dsherret dsherret changed the title refactor: use emit from swc instead of tsc perf: use emit from swc instead of tsc Jul 12, 2022
"experimentalDecorators": true,
"incremental": true,
"jsx": "react",
"jsxFactory": "React.createElement",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding these here appears to cause issues when "jsx" is set to "react-jsx".

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm… I can’t remember why I added these :/ (but it’s late here)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ref: #15263

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants