ScalafmtRunner: use Future, not .par
#4743
Conversation
kitbellew
force-pushed
the
4744
branch
3 times, most recently
from
c54b00d to
e5469dd
Compare
kitbellew
changed the title
.par.par
| termDisplay.stop() | ||
| exitCode.get() | ||
| runInputs(options, inputMethods, termDisplayMessage) { inputMethod => | ||
| import org.scalafmt.sysops.PlatformCompat.executionContext |
There was a problem hiding this comment.
Curiously, do we also enable multithreading in Scala Native as well this way? Maybe we don't need the separate executionContext anymore?
Maybe we can remove compatPar now also?
There was a problem hiding this comment.
- during building i see messages about multithreading enabled, perhaps we could somehow make it explicit
- compatPar will be removed but this is not the last place yet
- executionContext I'd keep in case we want to define a custom (i was playing with it) or support scala.js (it uses a different one)
i can't see much difference in speed in community test running, but it felt to me much faster when i ran the result of sbt cli/assembly with local snapshot version (forcing core runner, instead of dynamic).
There was a problem hiding this comment.
during building i see messages about multithreading enabled, perhaps we could somehow make it explicit
I think it's automatically disabled when not needed, so no need to make it explicit I guess?
i can't see much difference in speed in community test running, but it felt to me much faster when i ran the result of sbt cli/assembly with local snapshot version (forcing core runner, instead of dynamic).
Och, interesting! Do you mean the JVM version?
There was a problem hiding this comment.
yes, the JVM. native was even faster but i didn't check how native performed without this change.
No description provided.