-
Notifications
You must be signed in to change notification settings - Fork 279
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
Workflows: use native for community tests in CI #4758
base: main
Are you sure you want to change the base?
Conversation
82d040a
to
4b5b3c6
Compare
@tgodzik @jchyb i was working on this purely out of curiosity, and i don't understand the results. if you compare this latest test run using native (forgetting for a second that it failed), it is slower than the previous run which used jvm: native: https://github.com/scalameta/scalafmt/actions/runs/13086461314 native build takes 8 minutes, jvm a little over 1. jvm test of scala3: 11 minutes (https://github.com/scalameta/scalafmt/actions/runs/13085684687/job/36516501088) so, native is only 2 minutes faster, excluding the build step, which is hardly earth-shattering. both use the same approach, which includes futures for parallelism. i wonder... |
I wouldn't expected a large difference without anyone more competent than me looking into optimizing it. Though, shaving off 2 minutes is still good in my book. It's not so useful if you have to build the native binaries yourself. Potentially, we could build the binaries, upload them and download to run on a specific suite. |
It should be a little faster after merging #4789 (the previous very positive looking comparisons were made using 2.12, where that library was not necessary), but there's not much we can do about the long build times if we want to keep the runtime fast. |
i will review it, and it's generally useful, but we switched to using futures, so it will not have effect but perhaps we could review how we use futures. |
Ah, I see, it might not improve things much then |
No description provided.