4 ms·
We need more downstream projects like this putting pressure on the library authors to cut down their dependency trees as well as generic usage. Perhaps, we nee
by kvark 6y ago
We need more downstream projects like this putting pressure on the library authors to cut down their dependency trees as well as generic usage.
Perhaps, we need better tools for this. Take `cargo-bloat` for example: if library A makes a generic type from library B to monomorphize, would the build time reflected in `A`? It would be good to have something telling us: this API has a build complexity metric of 1.23 - something we could feature and/or track on CI.
- throwaway894345 6y agoI think "better tools" would be a good way to go. In general I think we need to make these things that we care about (performance, binary size, compilation time, etc) more visible and quantifiable and to allow us to easily root cause them. I think we need to make profiling these things dead simple and fast--with respect to performance, the time to get a flamegraph should be nearly zero, and the flamegraph's UI should be optimized (e.g., the ability to "peek" at a function's definition directly from the flamegraph). We need similarly easy ways to trace compilation time and code bloat to their causes in the code, perhaps even with automated suggestions for improvements.
- pjmlp 6y agoThis is mostly an issue because cargo doesn't handle binary libraries.