Skip to content
This repository has been archived by the owner on Mar 1, 2019. It is now read-only.

Better concurrency when lowering #157

Open
nrc opened this issue Nov 12, 2018 · 1 comment
Open

Better concurrency when lowering #157

nrc opened this issue Nov 12, 2018 · 1 comment

Comments

@nrc
Copy link
Member

nrc commented Nov 12, 2018

We do a lot of locking (every time we consult the project analysis) when lowering. We should be able to do better, at the least by using RW locks, but perhaps by being smart and doing some lock-free magic or some cloning

@nrc
Copy link
Member Author

nrc commented Nov 12, 2018

We could also use more fine-grained locking, at present we have a single lock over the whole analysis which is taken and dropped repeatedly. It would be more efficient to have finer grained locks and hold them for longer.

Given we don't actually make use of parallelism, we could just hold the lock for the whole of lowering (this is a bit tricky because we use the user-facing API which includes locking.

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

No branches or pull requests

1 participant