-
-
Notifications
You must be signed in to change notification settings - Fork 99
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
Optimize build times #203
Comments
As already said in #210, removing Nevertheless I'd say to remove So if the consensus is to remove |
#198 has largely removed |
Edit: Reorganized data, added relative build time. Build Time: 10m49.902s (single thread on Intel i3-5010U).
Time measurements from cargo-bloat |
The low hanging fruit here is deriving |
Am I correct that removing |
Indeed! Duplicates origin
I have checked and |
@malobre @omni-viral as I'm trying to vendor Please consider removing |
The next step is probably to hide Serialize and Deserialize behind different features as you previously suggested. |
I have time to work on that, but I have one question. |
@malobre good question! Rendy though would mostly care about what gfx-rs derives today, and that's just controlled by When you measured the times, why did Another question - was the |
Oh I see what the problem is, the timings were with all features enabled. So the As for the
After all these changes we will only be building |
So removing the |
Removing |
TBH I'm for getting rid of |
Is it though? From what we've seen before in #210, it isn't really that significant after all. This might be changed if we get rid of extra copy of @malobre I don't know tbh. I kinda start to think that it might be good idea to get rid of it, just to make it a bit easier on firefox dev team and alike. All the little libraries add up. My conern is that applying this logic to many other dependencies is dangerous. The concept of sharing code is useful after all, it can actually bring improvements to the build times. We just need to keep things up to date. Another kinda separate point is, I think we should focus a little bit more on making the rendy's code alone faster to compile. I'd love to have some kind of tools that tell me where the compiler spends most time, maybe we can help it a bit. Also a big factor for sure is the proliferation of generics that gets monomorphized in the user's code. It's really hard to get rid of some of them (notably backend), but maybe we can at least monomorphize them in rendy's code already. |
I agree about the dependency situation, this is all about finding an equilibrium. The About rendy code, I'll try to establish what takes time to compile and make a little summary so we have an idea where optimization would be nice. |
Self-profile results (anything over 2%)
|
Whoa, why |
One indirect The second one should be resolved in the next few days. (Summary: #203 (comment)) |
@omni-viral could you |
Current nightly compiler ICE on rendy without backend features. |
Ogeon/palette#145 has been closed, and (Edit: derivative still uses an older version of |
implemented dependabot to keep dependencies up to date, individual issues can be raised about time consuming dependencies, duplicates in tree, etc. palette upgrade has PR already would like to automate the timings result being posted to PRs, will file issue |
Removing
failure
andderivative
should be a solid step in this direction. See gfx-rs/gfx#2970 and also #198The text was updated successfully, but these errors were encountered: