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

wgpu-core Result values are quite large #3216

Open
jimblandy opened this issue Nov 18, 2022 · 2 comments
Open

wgpu-core Result values are quite large #3216

jimblandy opened this issue Nov 18, 2022 · 2 comments
Labels
area: api Issues related to API surface area: performance How fast things go type: enhancement New feature or request

Comments

@jimblandy
Copy link
Member

As reported by newer versions of Clippy via the result_large_err lint, several of the error types returned in wgpu-core are quite large. For example:

error: the `Err`-variant returned from this function is very large
    --> wgpu-core/src/command/render.rs:1023:10
     |
1023 |     ) -> Result<(UsageScope<A>, SurfacesInDiscardState), RenderPassErrorInner> {
     |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the `Err`-variant is at least 208 bytes
     |
     = help: try reducing the size of `command::render::RenderPassErrorInner`, for example by boxing large elements or replacing it with `Box<command::render::RenderPassErrorInner>`
     = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#result_large_err

As the Clippy help explains:

A Result is at least as large as the Err-variant. While we expect that variant to be seldomly used, the compiler needs to reserve and move that much memory every single time.

@cwfitzgerald
Copy link
Member

Did this get fixed by a recent PR from you?

@ErichDonGubler
Copy link
Member

@cwfitzgerald: AIUI, #3226 (which I presume you're referring to) was intended to stave off the immediate CI blocker that this lint would introduce from MSRV 1.65 onwards. I don't think any work has been done to actually establish that lint itself or its default size threshold is desirable for this project specifically, though.

I think it would be interesting to validate whether or not the workaround that #3226 intends is actually a good long-term solution. Perhaps we can change the scope of this issue to handle that instead?

@teoxoy teoxoy added type: enhancement New feature or request area: api Issues related to API surface area: performance How fast things go labels Feb 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: api Issues related to API surface area: performance How fast things go type: enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants