-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Move Throughput into sc-sysinfo
#12368
Move Throughput into sc-sysinfo
#12368
Conversation
I think it is also fine to split the issue into two MRs, depending on your preferences. |
Sure, that makes sense. |
sc-sysinfo
Yes, this is only preparation for #12017, I changed the description now. The CI doesn't seem happy, I will do some minor fixes on this. |
I also don't really get why we need |
The measurement of the performance at startup runs in |
@@ -45,6 +101,7 @@ pub struct Requirement { | |||
/// The metric to measure. | |||
pub metric: Metric, | |||
/// The minimal throughput that needs to be archived for this requirement. | |||
#[serde(serialize_with = "serialize_throughput", deserialize_with = "deserialize_throughput")] |
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.
Why do we need to support deserialize at all? @ggwpez?
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.
Ahh, now I see. Do we really need to serialize with the unit attached? I don't think we should do this. You can just serialize as mib and fine.
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 don't think we should do this, the reference_hardware.json
has values specified in other units also, of course, we can probably change that, but isn't it nicer to have the biggest possible unit used? @bkchr
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.
Yea the only reason to have units was the maintainability of that file. Although if we add an option to auto-generate it, then it should be fine either way.
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 mean normally you would just do it in bytes and fine. Like having there Mibs
etc also requires documentation, as no one knows which kind of units are supported.
let mut map = serializer.serialize_map(Some(1))?; | ||
let (value, unit) = t.normalize(); | ||
let unit_as_str = match unit { | ||
Unit::GiBs => "GiBs", | ||
Unit::MiBs => "MiBs", | ||
Unit::KiBs => "KiBs", | ||
}; | ||
|
||
map.serialize_entry(&unit_as_str, &value)?; | ||
map.end() |
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.
let mut map = serializer.serialize_map(Some(1))?; | |
let (value, unit) = t.normalize(); | |
let unit_as_str = match unit { | |
Unit::GiBs => "GiBs", | |
Unit::MiBs => "MiBs", | |
Unit::KiBs => "KiBs", | |
}; | |
map.serialize_entry(&unit_as_str, &value)?; | |
map.end() | |
let (value, unit) = t.normalize(); | |
serializer.serialize_str(&format!("{} {}", value, unit)) |
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.
@bkchr I explicitly requested that this will be done the way it is now. (:
See these comments why:
#12368 (comment)
#12368 (comment)
Maybe a comment in the code would be good why this match
is currently duplicated? Or just don't serialize/deserialize the units at all and keep it all in MB/s (but that's up to @ggwpez).
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.
Same argument as above - just the maintainability of the json file. Since having units is self explanatory, otherwise it needs docs to explain what it means.
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.
Hmm okay, I'm not really convinced of having the mibs etc be part of the json. However, I also don't really care. If @ggwpez is happy, he can approve and I will not complain.
daefc55
to
cbca2c2
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 dont have a strong opinion on the serialization stuff.
Co-authored-by: Oliver Tale-Yazdi <[email protected]>
@ggwpez So what is the final decision then? |
Okay then lets remove the unit from the serialization. Less code - less bugs. |
@ggwpez What should we do with Edit: wouldn't auto-generating it result in even more code? |
Change it so that it works with the new format.
We need auto-generation at one point anyway, as manual editing is error-prone and not straight forward. |
@ggwpez So I assume we should use MiBs in the |
@ggwpez can we merge this? |
bot merge |
Waiting for commit status. |
Prepares for #12017
Polkadot address: 126X27SbhrV19mBFawys3ovkyBS87SGfYwtwa8J2FjHrtbmA