I have a HashMap<String,HashMap<String,String>> pairs, roughly ~50,000 items for the outer hashmap and between 1-20 values for the inner hashmap.
I call the following method 300 times
pub enum PdlEntry {
COMMENT,
NUM(f64),
STR(String),
VNUM(Vec<f64>),
VSTR(Vec<String>),
}
pub fn get_field<'a, T: 'a>(name: &str, entries: &'a HashMap<String, PdlEntry>) -> result::Result<T, Error>
where
&'a HashMap<String, PdlEntry>: GetPdlData<T>,
{
entries
.get_pdl_data(name)
.ok_or(err_msg(format!("Could not find {} in entity {:?}", name, entries)))
}
And then repeat the exercise with this method
pub fn get_field2<'a, T: 'a>(name: &str, entries: &'a HashMap<String, PdlEntry>) -> Option<T>
where
&'a HashMap<String, PdlEntry>: GetPdlData<T>,
{
entries.get_pdl_data(name)
}
The overhead is quite dramatic. When using Result type the timings are
~5s
when using the Option object it’s closer to
0.01s
Compiled in release mode with timings tested by
let now = Instant::now();
let cpdm: PowerDual = PowerDual::try_from(&pdl).unwrap();
println!(
"Getting fixings end {}.{:03}",
now.elapsed().as_secs(),
now.elapsed().subsec_millis()
);
Should there be such a overhead using Result<> and, if so, I’m thinking that my code should generally be constructed using Option return types and only at the higher level use Result, especially not in inner loops.