-
Notifications
You must be signed in to change notification settings - Fork 285
sdk: lower compile times #3879
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
sdk: lower compile times #3879
Conversation
Not a review, but thank you for your service 🫡 |
227aa93
to
692561f
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3879 +/- ##
==========================================
- Coverage 84.10% 84.03% -0.07%
==========================================
Files 266 266
Lines 27724 27731 +7
==========================================
- Hits 23318 23305 -13
- Misses 4406 4426 +20 ☔ View full report in Codecov by Sentry. |
if let EventTimelineItemKind::Remote(remote_event) = &item.kind { | ||
if let Flow::Remote { encryption_info, .. } = &self.ctx.flow { | ||
new_item = new_item.with_kind(EventTimelineItemKind::Remote( | ||
remote_event.with_encryption_info(encryption_info.clone()), | ||
)); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A small note: this is slightly changing behavior, because I thought the previous behavior was buggy.
Previous behavior did this: if the item comes from a local echo, use an encryption_info
set to None
, and replace it in the original timeline item.
With the new behavior, we override the encryption_info
only if the new information comes from a remote echo.
Incidentally, @pixlwave opened an issue which I think describes that, today: #3882. Happy to move the change to a separate PR if it's preferred; since it was only a 3 lines change, I deemed it not useful. But it's worth highlighting for the review here, since this is the only functional change of this PR overall.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, I can confirm that this fixes the issue 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine keeping the change here.
…it with functions After this, compiles times for matrix-sdk-ui are reduced from 44 seconds to 30 seconds on my machine.
These are function parameters, they shouldn't be cloned for no good reason.
It was found that it's making the whole build slower because it's hitting a pathologically slow path in type-checking. Considering that it doesn't do much, let's get rid of it and inline it instead. After this, compiles times are reduced from 30 seconds to 22 seconds on my machine
It's one fewer pathologically slow type query during type-checking, and a build time for matrix-sdk-ui 5 seconds lower.
Who has two thumbs and wants to make a trait not use async_trait, and thus get rid of trait object safety?
This divides compile times for matrix-sdk by 2, on my machine (33 seconds -> 16).
692561f
to
610c1b8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I love what I've read. Excellent work!
@@ -103,7 +102,6 @@ pub(super) enum Flow { | |||
}, | |||
} | |||
|
|||
#[derive(Clone)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
\o/
@@ -73,7 +73,6 @@ use crate::{ | |||
}; | |||
|
|||
/// When adding an event, useful information related to the source of the event. | |||
#[derive(Clone)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
\o/
if let EventTimelineItemKind::Remote(remote_event) = &item.kind { | ||
if let Flow::Remote { encryption_info, .. } = &self.ctx.flow { | ||
new_item = new_item.with_kind(EventTimelineItemKind::Remote( | ||
remote_event.with_encryption_info(encryption_info.clone()), | ||
)); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine keeping the change here.
@@ -43,7 +44,7 @@ pub trait RoomExt { | |||
/// independent events. | |||
/// | |||
/// This is the same as using `room.timeline_builder().build()`. | |||
async fn timeline(&self) -> Result<Timeline, timeline::Error>; | |||
fn timeline(&self) -> impl Future<Output = Result<Timeline, timeline::Error>> + Send; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm even wondering if we can use async fn
in traits since we are targeting a recent Rust version. I'm lazy checking though. I'm fine with -> impl Future
, which is exactly the same.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was coming back here to ensure the + Send
bound is present. It is present. Well done :-].
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the review!
The compiler warns if we use async fn
, and we have some builds with warn-as-errors, so it fails those builds. The reasoning is that using an async fn
in trait doesn't tell anything about the bounds of the future, so it eventually is it that recommended to return an impl Future
.
@@ -26,7 +26,6 @@ async_cell = "0.2.2" | |||
async-once-cell = "0.5.2" | |||
async-rx = { workspace = true } | |||
async-stream = { workspace = true } | |||
async-trait = { workspace = true } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
\o/
This series of patches, investigated using Fasterthanlime's good advice, helped lowering the compiles times from 44 seconds to 4 on my machine, for the
matrix-sdk-ui
crate.Compile times for the
matrix-sdk
crate have also been lowered from 33 to 12 seconds.Overall, for a plain
cargo build
:Each commit can be reviewed independently.
See also: rust-lang/rust#87012