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

Try merging Resolver and Typechecker into one pass #32

Open
kubouch opened this issue Dec 28, 2024 · 7 comments
Open

Try merging Resolver and Typechecker into one pass #32

kubouch opened this issue Dec 28, 2024 · 7 comments
Labels
performance Issues related to performance

Comments

@kubouch
Copy link
Collaborator

kubouch commented Dec 28, 2024

Merging the resolving and typechecking passes into one might help performance. The resulting pass can be called “semantic analysis”, or “Sema”.

@kubouch kubouch added the performance Issues related to performance label Dec 28, 2024
@InnocentZero
Copy link
Contributor

I'll take on this.

@kubouch
Copy link
Collaborator Author

kubouch commented Dec 29, 2024

OK, it would be good to know the performance tradeoff, since having the passes separate is preferred because it's more readable. The combined1000 benchmark is probably the most representative, but you can come up with some better one. You can use tango for A-B benchmarking via path/to/benchmark1 compare path/to/benchmark2 ...args. See also https://github.com/nushell/nushell/blob/4ff4e3f93de89702219d1559fd8cfa9122dd14b2/toolkit.nu#L500.

@kubouch
Copy link
Collaborator Author

kubouch commented Jan 1, 2025

@InnocentZero See #38, we should probably fix our benchmarks first before optimizing.

@kubouch
Copy link
Collaborator Author

kubouch commented Jan 2, 2025

The benchmarks are fixed, and the new parser seems to be at least 10x faster in most benchmarks, which is good. But the combinedX.nu benchmarks scale less efficiently than the old parser. Every 10x increase in code size, the new parser scales about 20x, while the old one is closer to 10x. So it would still be interesting to see how the performance would be with the two passes merged.

@sholderbach
Copy link
Member

Let's analyze which parts don't scale well before rushing to make that single pass

@InnocentZero
Copy link
Contributor

I guess we need finer benchmarking tests to see which parts don't scale well wrt code size. I can write a few tests if that's ok with all of you.

@kubouch
Copy link
Collaborator Author

kubouch commented Jan 3, 2025

Yeah, why not. We might also want to wait until the compiler is more complete, it's still missing several fundamental parts.

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

No branches or pull requests

3 participants