Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible bloat from over-use of default methods on trait objects #12449

Closed
zkamsler opened this issue Feb 21, 2014 · 2 comments
Closed

Possible bloat from over-use of default methods on trait objects #12449

zkamsler opened this issue Feb 21, 2014 · 2 comments
Labels
I-compiletime Issue: Problems and improvements with respect to compile times. I-slow Issue: Problems and improvements with respect to performance of generated code.

Comments

@zkamsler
Copy link
Contributor

I am not sure if this is an issue as such, but I figured that I ought to mention it.

I don't know the current linker behavior, but the best case is that all implementations of default methods for types that are coerced to trait objects must be generated and cannot be stripped because they are referenced by their vtable. As a result, there are a may be a number of method implementations that cannot be removed even if they do not happen to be used.

This is most notable for the io::Writer and io::Reader traits, which are often used behind trait objects and have a number of default methods. Writer has 28 default methods (not including flush and by_ref), which is up to 513 methods over 19 implementations. Reader has 31 default methods (not including by_ref and bytes), which is up to 620 methods over 20 implementations.

I do not mean to suggest that default methods should not be used for traits that are often uses as trait objects, but merely that some care should be used when adding them. In some cases things like such as wrapper structs, or the unpopular trait-just-to-add-methods may be appropriate.

@glaebhoerl
Copy link
Contributor

Or the unpopular top-level fns.

@thestinger thestinger added I-slow Issue: Problems and improvements with respect to performance of generated code. I-compiletime Issue: Problems and improvements with respect to compile times. labels Sep 19, 2014
@alexcrichton
Copy link
Member

This issue itself is not particularly actionable due to the lack of statistics about what sort of size increase we're looking at. This sounds like it's definitely something to keep in mind, but there's not a whole lot we can particularly do today so I'm going to close this.

bors added a commit to rust-lang-ci/rust that referenced this issue Jul 25, 2022
matthiaskrgr pushed a commit to matthiaskrgr/rust that referenced this issue Mar 21, 2024
Add new lint `zero_repeat_side_effects`

Fixes rust-lang/rust-clippy#6439

Adds a new `suspicious` lint zero_repeat_side_effects. This lint warns the user when initializing an array or `Vec` using the `Repeat` syntax, i.e., `[x; y]`. If `x` is an `Expr::Call/MethodCall` or contains an `Expr::Call/MethodCall` and `y` is zero, then there is a chance that the internal call can produce side effects, such as printing to console, which is not very obvious.

This lint warns against this and instead suggests to separate out the function call and the array/Vec initialization.

changelog: Add new lint `zero_repeat_side_effects`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I-compiletime Issue: Problems and improvements with respect to compile times. I-slow Issue: Problems and improvements with respect to performance of generated code.
Projects
None yet
Development

No branches or pull requests

4 participants