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

[ide/cache] signature-based module invalidation #9995

Open
nadako opened this issue Dec 17, 2020 · 1 comment
Open

[ide/cache] signature-based module invalidation #9995

nadako opened this issue Dec 17, 2020 · 1 comment

Comments

@nadako
Copy link
Member

nadako commented Dec 17, 2020

Creating this issue to write down an idea for possible significant performance improvements for the cache server (and as a consequence - IDE performance).


The problem:

Currently if module A uses module B and we change module B in any way - module A will invalidate, causing its dependants to invalidate as well and so on. As a result there is a lot of potentially redundant re-typing happening on every change, which especially hurts IDE performance a lot.


The idea:

We can NOT invalidate module A if module B has changed but it's signature stayed the same, where signature is: defined public types, field names and types.

So if you change something at expression level and that doesn't affect the API of the module - we don't invalidate dependants.


Notes:

There are potential problems with inlining, but we can be conservative for a start and use the "full" dependency if we inline something from a module and figure out something better later.

Detecting the signature changes might require re-typing the changed module (especially if monomorphs are involved in field types), but it's what we already do anyway and it's still better to re-type one module, detect that its signature hasn't changed and not invalidate its dependants than to always invalidate and re-type like we do now.


Some extra thoughts by @Simn:

11:50
I think as a first step we have to model dependents as (module * whatever)
11:51
There's probably three levels: 1. nothing changed 2. signature changed 3. everything changed

@RealyUniqueName RealyUniqueName added this to the Backlog milestone Dec 17, 2020
@Simn Simn modified the milestones: Backlog, Later Mar 24, 2023
@kLabz
Copy link
Contributor

kLabz commented Jul 19, 2024

We're now pretty much doing that whenever possible (though current implementation is more conservative, and considers more things as dependencies).

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

No branches or pull requests

4 participants