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

Slow #202

Open
5 tasks
thumphries opened this issue Mar 23, 2017 · 1 comment
Open
5 tasks

Slow #202

thumphries opened this issue Mar 23, 2017 · 1 comment

Comments

@thumphries
Copy link
Contributor

The typechecker is fast, and the parser is fast enough, but the last mile introduces a fair amount of slow.

When this really starts to grate and we decide to do something about it, there's a fair bit of low hanging fruit:

  • Serialise intermediate state to disk so we can actually run incrementally
    • maybe we don't want to do this, would be finicky, but is the quickest solution
  • Builds should be streaming, currently there's a pointless outer Either restricting throughput
  • Fuse various traversals together. We probably walk every expression about 30 times before it hits the disk, for typechecking, type substitution, rewriting, let substitution, backend predicates, warnings, and evaluation/interpretation
  • Dependency order could be a rose tree instead of a list, exposing plenty of parallelism
  • eval and subst are extremely naive and slow, quadratic even, with some effort we could knock an order of magnitude off
@thumphries
Copy link
Contributor Author

I benchmarked loom on Friday and subst was a major bottleneck.

I also experimented a bit with parallel codegen and parsing. Codegen saw some payoff from parMap / chunked list strategy, but overall there are too many eithers forcing values prematurely to get much value from this. It knocked about 150ms off overall.

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

1 participant