TlsConnector::new and TlsAcceptor::new both take a TlsConnectorConfig/TlsAcceptorConfig but they could easily take a &TlsConnectorConfig/&TlsAcceptorConfig instead.
So lets do that.
Once changed we will need to find all the locations that call new and swap the Clone::clone() with an Option::as_ref:
- let tls = self.tls.clone().map(TlsConnector::new).transpose()?;
+ let tls = self.tls.as_ref().map(TlsConnector::new).transpose()?;
Here, Option::as_ref takes an &Option<TlsConnectorConfig> and returns it as Option<&TlsConnector>.
This is important because we need the value that the function in .map(..) is given to be &TlsConnector instead of TlsConnector.
If this were a code path that every message took this would be a nice performance improvement.
In reality this wont make shotover any faster since the code path only occurs during shotover's initialization, so it will only make initialization a tiny bit faster.
But its a nice isolated introduction to working with borrows vs clones and makes the code follow patterns used in the rest of the codebase.
TlsConnector::newandTlsAcceptor::newboth take aTlsConnectorConfig/TlsAcceptorConfigbut they could easily take a&TlsConnectorConfig/&TlsAcceptorConfiginstead. So lets do that.Once changed we will need to find all the locations that call
newand swap the Clone::clone() with an Option::as_ref:Here,
Option::as_reftakes an&Option<TlsConnectorConfig>and returns it asOption<&TlsConnector>. This is important because we need the value that the function in.map(..)is given to be&TlsConnectorinstead ofTlsConnector.If this were a code path that every message took this would be a nice performance improvement. In reality this wont make shotover any faster since the code path only occurs during shotover's initialization, so it will only make initialization a tiny bit faster. But its a nice isolated introduction to working with borrows vs clones and makes the code follow patterns used in the rest of the codebase.