The following is a table of lto and lto+pgo download stats for *.tar.zst release assets having both variants published:
Target
lto Downloads
pgo+lto Downloads
aarch64-apple-darwin
1089
36279
i686-unknown-linux-gnu
463
768
x86_64-apple-darwin
1730
37022
x86_64-unknown-linux-gnu
6450
885036
x86_64_v2-unknown-linux-gnu
324
15393
x86_64_v3-unknown-linux-gnu
284
30464
The LTO only builds are getting a small percentage of downloads relative to the PGO+LTO builds.
I can't recall why we are even publishing LTO only distributions when PGO+LTO exists. In the case of PyOxidizer we prefer PGO only (because LTO object files are LLVM bitcode, which is unsafe to re-link unless you are using the same LLVM toolchain as the one that produced them). But I can't think of a good reason why we need to publish LTO only.
So I'm proposing we stop publishing LTO only distributions when a PGO+LTO build exists.
Please leave a comment with objections if you have any.
In the absence of compelling arguments to preserve them, the LTO only .tar.zst release assets will be removed from a future release.
The following is a table of
ltoandlto+pgodownload stats for*.tar.zstrelease assets having both variants published:ltoDownloadspgo+ltoDownloadsThe LTO only builds are getting a small percentage of downloads relative to the PGO+LTO builds.
I can't recall why we are even publishing LTO only distributions when PGO+LTO exists. In the case of PyOxidizer we prefer PGO only (because LTO object files are LLVM bitcode, which is unsafe to re-link unless you are using the same LLVM toolchain as the one that produced them). But I can't think of a good reason why we need to publish LTO only.
So I'm proposing we stop publishing LTO only distributions when a PGO+LTO build exists.
Please leave a comment with objections if you have any.
In the absence of compelling arguments to preserve them, the LTO only
.tar.zstrelease assets will be removed from a future release.