Improve build times. #311
Comments
|
I really like this idea. You could have the default feature include ever codec, but if I have a crate that only uses PNG and JPEG, then I could just select those. |
|
Good idea. I woud prefer feature flags. I don’t want to maintain 6 crates on crates.io |
|
The problem with feature flag is they only allow one feature set at a time, which must be named. Example https://github.com/bvssvni/start_piston/blob/master/Cargo.toml#L90-L98 |
|
We can use a "only_jpeg_png" feature flag and leave out the other codecs when this is enabled. |
|
No, please. Let's say you have library A which depends on If you try to use both A and B at the same time, Cargo will compile |
|
We could move codecs into smaller crates, and make them depend on this library. In the long term this is a better solution. We should figure out a way to make working with crates.io a less burden on the maintainers. |
|
When I tried to at least add a feature flag I ran into problems with dynimage.rs. You can use a feature flag to remove enums, but table entries is not possible. |
|
Also, see rust-lang/cargo#1169 If Cargo get this, then working with multiple crates could be easier. |
|
It seems that multiple features are supported, there is a bug in the command line, but works in Cargo.toml. I opened rust-lang/cargo#1378 |
|
IMHO the best way to improve compilation times (and improve implementation of new formats) is to split format encoders and decoders to separate crates (possibly in the same repo) and compile them only when needed. Just add "meta crate" that will contain common traits. |
|
The build times really degraded. Since we did not change much it must be partially a rustc thing… |
|
A month ago a release build took 1 minute (30s for image crate) on my computer. Now it is 2. From this two minutes image takes 1:30. That means the build times of image trippelt. |
The default continues to have all codecs activated, but a user can
opt-in to only supporting specific ones, via features, e.g. depending on
`image`, while only supporting JPEG and GIF:
[dependencies.image]
version = "0.2"
default-features = false
features = ["jpeg", "gif"]
On my computer `cargo build` takes ~95s, while `cargo build --features
jpeg --no-default-features` (only JPEG) takes ~28s.
This patch also updates the travis file to also compile the library with
each feature, to ensure they continue to compile. These codec features
are all independent, so testing each one individually is sufficient.
Closes image-rs#311.
The default continues to have all codecs activated, but a user can
opt-in to only supporting specific ones, via features, e.g. depending on
`image`, while only supporting JPEG and GIF:
[dependencies.image]
version = "0.2"
default-features = false
features = ["jpeg", "gif"]
On my computer `cargo build` takes ~95s, while `cargo build --features
jpeg --no-default-features` (only JPEG) takes ~28s.
This patch also updates the travis file to also compile the library with
each feature, to ensure they continue to compile. These codec features
are all independent, so testing each one individually is sufficient.
Closes image-rs#311.
The default continues to have all codecs activated, but a user can
opt-in to only supporting specific ones, via features, e.g. depending on
`image`, while only supporting JPEG and GIF:
[dependencies.image]
version = "0.2"
default-features = false
features = ["jpeg", "gif"]
On my computer `cargo build` takes ~95s, while `cargo build --features
jpeg --no-default-features` (only JPEG) takes ~28s.
This patch also updates the travis file to also compile the library with
each feature, to ensure they continue to compile. These codec features
are all independent, so testing each one individually is sufficient.
Closes image-rs#311.
|
Ok, I think it wasn’t our fault that the compile times exploded: rust-lang/rust#25069 |
I was wondering if there was any ideas on how the build times could be improved for this crate. It currently takes about a 1minute to compiler for a none release build.
Some ideas:
featureflags to disable codecs that are not usedThe text was updated successfully, but these errors were encountered: