Skip to content

[windows] switching to ld.lld.exe linker instead of gnu ld.exe #1108

Description

@ghyatzo

Hello,

apparently the ld.exe that ships with the mingw distribution used by PackageCompiler is abysmally slow on windows for some reason. (also msys2/MINGW-packages#7660)
Switching to lld makes linking basically instant in comparison.

See this example:

PS C:\Users\camillo.schenone\PackageCompilerExperiment> .\bench_ld_lld.ps1
LLD: (seconds)
1,7023733
GNU ld: (seconds)
65,9871613
PS C:\Users\camillo.schenone\PackageCompilerExperiment> # now a big one (changed the target object)
PS C:\Users\camillo.schenone\PackageCompilerExperiment> .\bench_ld_lld.ps1
LLD: (seconds)
5,0109449
GNU ld: (seconds)
3016,478836 (yeah...)

first one links a modest object (a sysimage with only 2 lightweight packages, 300 MB -o.a object) and the second one is much bigger (CairoMakie and others, ~2GB compiled -o.a).

Now, the methodology is a bit questionable. I basically "monkey patched" the mingw distribution used by PackageCompiler by swapping the provided ld.exe with a statically linked version of ld.lld.exe stolen from the latest LLVM release and copying the compiler invocation to link the intermediate -o.a product. But this was mainly to see if there was an actual difference or not.

The results are quite astounding to be honest. Are there any blockers to using a different version of mingw for PackageCompiler on windows?
As it stands linking takes more than compiling (the big sysimage example took ~40minutes to compile, 50 to link).

Both generated sysimages are loaded without issues.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions