I saw some other crate doing something similar but using wasm, the idea is to sandbox the binary used as a proc macro. So that seems a bit better. Can’t see to find it any more.

EDIT: Found it https://lib.rs/crates/watt

Debug builds link in <.4 seconds.

With such a small program I expected fixed costs to dominate. Not surprising there is no or almost no difference. You really have to go to cases where linking takes 10s of seconds to see scaling difference, even between ld.bfd and ld.gold.

I did those sort of measurements for my work at the time (a few years ago, before mold was a thing). I have not had the cause or opportunity to measure lld or mold however. Maybe it isn’t faster than lld (certainly it seems so for small projects), but I don’t think these result say anything useful about larger programs.

The best option is not to take the word of others (myself included) however, but measure on your own application and see which is the best option in your case.

If you however do want to measure linking something big, look at something like Chromium. That isn’t rust code though. Not sure what a suitably large rust project would be.

1. With a total build time of less than 2 minutes, my guess is that link time is fairly small. At work we have a c++ project that takes around 40 minutes to build. Only in the incremental case does link time dominate (upwards of 10 seconds with gold, haven’t tried lld or mold).

2. My understanding is that mold supposedly has more scalable data structures and algorithms (better complexity). Thus for small links there likely will be little difference. So you need to measure it on your actual use case to see if it makes a difference.

3. mold supposedly can take more advantage of multi core. How many cores did you run on? Again this will likely not show for small links, since there is also overhead in splitting work across threads.

Disclaimer: I love the lib.rs search and general UI. I don’t like crypto currencies.

I think the way to avoid drama is to be very clear and transparent in communication. In this case I think a way to do this would be to label data that lib.rs synthesised. Maybe a asterix next to corrected categories that on mouse over (long press on phones) says something like “inferred by lib.rs due to missing data”? Exact wording could certainly be improved, and might differ on context. Perhaps the synthesised data could be a different colour as well to stand out.

Having a list of packages that were filtered out might also help. Here I’m thinking a simple text file (set to not be indexed in robots.txt) with all the package names that have filtered along with the reason listed (e.g. “auto detected name squat”). Anyone interested could download the file and take a look, as well as contact you for corrections.

Ranking algorithms is harder to be transparent about (and it is not my field of expertise), so I can’t offer any advise here. Perhaps nothing is needed?

Actually you don’t need to build your own. The rust on esp project provide a espup tool that downloads a pre built toolchain for Xtensa.