-
-
Notifications
You must be signed in to change notification settings - Fork 560
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
feat(rust): avoiding memory fragmentation by reducing allocations #8640
base: develop
Are you sure you want to change the base?
Conversation
bee4614
to
d432379
Compare
d93bed7
to
c73ab96
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.
Very nice improvements!
implementations/rust/ockam/ockam_vault/src/software/vault_for_signing/vault_for_signing.rs
Show resolved
Hide resolved
@@ -85,7 +80,7 @@ impl LocalMessage { | |||
|
|||
/// Prepend an address on the onward route | |||
pub fn push_front_onward_route(mut self, address: &Address) -> Self { |
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.
If we always clone an argument inside the function, we should pass that argument as a value instead of a reference. That will allow us avoiding clone in cases where calling side can give away ownership of the object.
P.S. It's OK if you don't want to make that change in that PR
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.
P.P.S. We have are a lot of such places even in this file
implementations/rust/ockam/ockam_core/src/routing/message/local_message.rs
Show resolved
Hide resolved
@@ -659,7 +659,7 @@ impl NodeInfo { | |||
pub fn status(&self) -> NodeProcessStatus { | |||
if let Some(pid) = self.pid() { | |||
let mut sys = System::new(); | |||
sys.refresh_processes(ProcessesToUpdate::All, false); | |||
sys.refresh_processes(ProcessesToUpdate::Some(&[Pid::from_u32(pid)]), false); |
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.
From my memory that didn't work. @adrianbenavides could you please take a look?
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.
To me, node list
and node show
are working
@@ -108,7 +108,7 @@ pub enum PortalInternalMessage { | |||
} | |||
|
|||
/// Maximum allowed size for a payload | |||
pub const MAX_PAYLOAD_SIZE: usize = 48 * 1024; | |||
pub const MAX_PAYLOAD_SIZE: usize = 96 * 1024; |
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 suspect that something like 65 should be enough. I doubt we can get more than that in one read. <=== just a guess
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 also wonder if we should consider how that data will be sent and split into packets after passing secure channel and getting to the TCP or UDP transport
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 suspect that something like 65 should be enough. I doubt we can get more than that in one read.
We are actually still far away from the performance impact of managing multiple TCP packets in a single read.
The only reason it actually increases the performance, it's due to the reduced number of ockam messages being processed, which reduces the overhead.
It's a diminishing return, for example locally, with 60 the throughput gets to ~13.5, with 96 it's ~16.7, and with 256 it's ~21. 96 felt like a good tradeoff.
I also wonder if we should consider how that data will be sent and split into packets after passing secure channel and getting to the TCP or UDP transport
We should definitively bring down the size to 60 to allow passing through a single UDP packet as soon as the overhead is low enough.
implementations/rust/ockam/ockam_identity/src/secure_channel/key_tracker.rs
Outdated
Show resolved
Hide resolved
implementations/rust/ockam/ockam_identity/src/secure_channel/key_tracker.rs
Outdated
Show resolved
Hide resolved
c73ab96
to
0b9d541
Compare
0b9d541
to
5b04957
Compare
This PR addresses the memory fragmentation from two sides, first many mini-allocations are avoided, mostly around
Route
, but also avoiding extra unused allocation in.ok_else(XXX)
.To improve the benefits, the payload size was also increased to 96KB. This also means that the minimum bandwidth for a stable portal is 1Mbits.
BEFORE:
AFTER: