Repository navigation
Windows ifort/ifx: older Intel installer packages are 3-4x slower on windows-2022 than windows-2025 #272
Description
TL;DR: ifort/ifx installs on windows-2022 can take up to 33 min (vs 3-7 min on windows-2025) — this traces to a known, years-old GitHub Actions platform issue (devenv slow to initialize on Windows runners) that's unlikely to ever get fixed upstream. Recommend pinning ifort ≥2021.10 / ifx ≥2023.2.0+ to avoid it entirely — full findings below.
Every "Install ifort" step over 10 min I've sampled (up to 33 min) was on windows-2022 — same versions finish in 3-7 min on windows-2025. Confirmed genuine (not a misrouted image) and not already tracked in existing issues/PRs.
Root cause, confirmed via Intel's own installer logs + a process/network capture: installing VS2022 integration triggers devenv.exe /updateConfiguration (Visual Studio's own extension-cache rebuild, run automatically per VSIX install) 17 times in one sample, back-to-back — accounting for nearly the entire slow window. Worse: this action already passes -p=NEED_VS2019_INTEGRATION=0 -p=NEED_VS2022_INTEGRATION=0 (win32.ts:131) to disable exactly this, but Intel's installer overrides it for several VS-integration sub-components anyway, installing 15 .vsix packages via VSIXInstaller.exe regardless.
Not an Intel-specific bug — devenv being slow to initialize on GitHub Actions Windows runners is a known, unresolved platform issue, reported as far back as 2019 (actions/virtual-environments#128 — even seen on Azure DevOps using the same base images) and still ongoing (actions/runner-images#5301, reports as recent as 2025). GitHub's own pre-warming attempt reportedly doesn't work; other runner providers report the same with no fix. Other Intel oneAPI + VS2022 users report the identical symptom independently (Intel Community thread: "an absolutely outrageous install/uninstall time"). So "make devenv fast" isn't achievable from this repo's side — only "avoid triggering it" was ever viable, and I tried every reasonable way (below).
-
Only affects older oneAPI packages, confirmed independently on
ifortandifx:ifort≤2021.9 andifx≤2023.1.0 are consistently slow onwindows-2022; newer versions are consistently fast — on both images. Two independent version-numbering schemes land on the identical boundary (oneAPI package2023.1.x→2023.2.x) — Intel likely fixed this themselves in the 2023.2 release. -
Not new, not specific to this repo's
v2rewrite: a production run from Sept 2 using the oldv1bash-based installer (different code entirely) shows the same shape and confirms the same boundary:Version oneAPI package windows-2022 2021.6 2022.2.0 (old) 16m 35s 2021.9 2023.1.0 (old) 33m 06s 2021.10 2023.2.1 (new) 6m 18s 2021.11 2024.0.2 (new) 8m 17s 2021.12 2024.1.0 (new) 6m 52s
Dead ends investigated along the way
- Disk I/O / Windows Defender scanning — mounted a trusted ReFS Dev Drive and redirected the install path +
TEMP/TMPonto it. Only ~6% faster. Makes sense in hindsight:devenv /updateConfigurationis VS's own cache-rebuild logic, not primarily a file-copy operation. - Intel telemetry consent — tried
--intel-sw-improvement-program-consent decline. No measurable effect (unrelated system). - Suspected network-bound — duration was highly variable (12-20 min for the same operation across runs) and DNS-resolved an Intel registration host mid-install, which looked network-related. Turned out to be a red herring: packet capture showed that connection completes in under a second, essentially at the very end, not something the install is blocked waiting on. The real variability comes from how many
devenvreconfiguration passes a given run triggers. - Tried:
--componentsselection to exclude the.ide/VSIX components entirely (the same approach this repo's own predecessor tool used, and thatifx's installer (win32.ts:352-358) still does today viasupportsComponentFilter/resolveFortranComponentId). Tested directly againstifort 2021.9(oneAPI2023.1.0) — no effect at all: the install log still showed the full, unfilteredhpckit.productand every.ide.*component installed anyway, same ~17 min duration. This repo's own historicalv1install script used a second, different--components=syntax — also had no effect (the Sept 2 production run above used it and still took 33 min). Confirmed conclusively with--list-components: empty output, exit code 0 — this installer generation doesn't implement component enumeration/filtering at all, on any syntax.ifx's ownLEGACY_KIT_VERSIONSset already excludes exactly2022.2.0/2022.3.0/2023.1.0/2023.2.0from component filtering — someone already learned this the same way. - Tried: hiding
vswhere.exeso Intel's installer couldn't detect Visual Studio (installers commonly shell out to it for VS discovery). No effect — the install log still showedPreRequisite for Visual Studio running... passedand every.ide.*component still selected, meaning Intel's installer detects VS through some other mechanism (most likely the VS Setup Configuration COM API directly, whichvswhere.exeitself just wraps).
Open question
Worth documenting this recommendation somewhere users would see it (README compatibility matrix? migration guide?), since no code-level fix exists?
(Note: while investigating this, I also found this repo's Actions cache is separately overwhelmed by unrelated cross-compiler quota pressure — filed as #273 since it's a different root cause.)
Activity
minhqdao commentedon Sep 29, 2026
Yes, looks like older
ifort/ifxversions can be significantly slower onwindows-2022.That said, I expect most users to either use
latestor pin a recent version. We offer the older versions mainly for reference/compatibility, which is something most compiler setup actions don't provide. If someone specifically needs an older version, I assume they have a reason for doing so, and the additional install time is probably less important.I think the most we can do here is add a short note to the README mentioning this (not the migration guide, since the behavior is the same before and after the migration). I'll do that if that works for you.
djkees commentedon Sep 29, 2026
I think that is the best option for all the reasons you mentioned
minhqdao commentedon Sep 29, 2026
Great find!
Addressed here: 1db8b60
Confirmed here: #245 (comment)