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::new
andTlsAcceptor::new
both take aTlsConnectorConfig
/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:Here,
Option::as_ref
takes 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&TlsConnector
instead 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.