Conversation
|
This appears to break TestUtils code that provides an exception for the output timestamp: Line 216 in 6740893 |
I agree. I think another point in favour of this approach is that if there does happen to be a change very far upstream, the compiler will have a lot of work to do rebuilding all of the downstream modules, so you're probably going to be waiting a little while anyway. |
|
@hdgarrood Does this look correct? Tests are passing for me at least. Another option is to give |
hdgarrood
left a comment
hdgarrood
left a comment
There was a problem hiding this comment.
Looks good to me :) I think it might be worth getting @kritzcreek to weigh in too, as he has actually worked on this code before, unlike me
natefaubion
force-pushed
the
concurrent-extern-loading
branch
from
3d8b8f0 to
76f5a05
Compare
|
Shall we merge this one now too? The same reasoning applies here as for the CST one I think - having it in master for a bit before the next release is probably the best way of testing it properly now. I don't want to put pressure on Christoph to review since he's very busy at the moment. |
3 participants
Previously externs were loaded serially with
foldM. This means that if a change is detected farther upstream, it won't try to read downstream externs. This PR loads and parses them all concurrently, which will result in downstream results that are thrown away if there are upstream changes. However, I think this is a decent tradeoff since during development, changes generally happen downstream.On my machine, with 551 modules compiled and a noop call to
purs compile, v0.12.5 takes ~4s, while this PR takes ~2.6s, and with the parser changes as well in #3608 it takes ~1.6s.