Skip to content

Conversation

@kitbellew
Copy link
Collaborator

Previously, we simply wrapped a Future around a blocking file I/O both on JVM and Native; while we still keep this approach on Native, let's implement actual asynchronous file I/O on JVM, just like on JS.

Also, modify runners to use this async writing and a different thread pool for that, so that it does not clash with formatting tasks.

@kitbellew kitbellew force-pushed the 4822 branch 2 times, most recently from 79bda26 to 9fc3447 Compare February 15, 2025 20:12
@agilesteel
Copy link

Just curious... Did you notice any performance improvements? Would be great. It takes a while to check formatting in a large code base...

@kitbellew
Copy link
Collaborator Author

Just curious... Did you notice any performance improvements? Would be great. It takes a while to check formatting in a large code base...

Not really. The build includes community-test checks, and they take about the same time. But they are not slower, and someone might suggest additional tuning. The main purpose is to use the same design for all three platforms, and scala.js, apparently, is inherently asynchronous.

@kitbellew kitbellew force-pushed the 4822 branch 2 times, most recently from ade6a5e to 25e8a8f Compare February 16, 2025 02:56
Previously, we simply wrapped a Future around a blocking file I/O both
on JVM and Native; while we still keep this approach on Native, let's
implement actual asynchronous file I/O on JVM, just like on JS.

Also, modify runners to use this async writing and a different thread
pool for that, so that it does not clash with formatting tasks.
@kitbellew kitbellew merged commit 7a3419a into scalameta:main Feb 16, 2025
32 checks passed
@kitbellew kitbellew deleted the 4822 branch February 16, 2025 05:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants