-
Notifications
You must be signed in to change notification settings - Fork 275
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
Remove unused crates from the project #4179
Conversation
And add a lint which helps make sure we keep removing unused crates in future.
@garypen, please consider creating a changeset entry in |
CI performance tests
|
That enables us to remove our dev dependency on redis.
We use rstack in linux only tests.
It's interesting and has helped me find some small improvements, but I don't think we can leave it always enabled because it is difficult to debug other platforms (i.e. not the platform you are doing the investigation on) and throws up some false positives. Maybe worth repeating the experiment every X months and manually making improvements.
I don’t find the lint in the diff. Is it meant to be a new file? |
|
the goal of using a different client was to make sure that there's nothing specific to fred that would mess with the data, but we can remove it yes |
I did wonder about that, but concluded that we should be testing |
Remove some unused crates and convert our redis tests to use the
fred
crate. That means we can remove our dev dependency on theredis
crate.This yielded a 1.5% reduction in test build time on my laptop.
Note: This is an exploratory PR, since it's fairly tricky to get unused crates information across multiple platforms with various conditional compilations in play.
Checklist
Complete the checklist (and note appropriate exceptions) before the PR is marked ready-for-review.
Exceptions
Note any exceptions here
Notes
Footnotes
It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this. ↩
Configuration is an important part of many changes. Where applicable please try to document configuration examples. ↩
Tick whichever testing boxes are applicable. If you are adding Manual Tests, please document the manual testing (extensively) in the Exceptions. ↩