In this commit, we add some docs that explain how to use tools like
heap escape analysis and memory profiling to fully eliminate allocations
in a sample program.
This guide is meant to help devs/contributors use Go's excellent perf
tools to zoom in on an optimization problem.
In this commit, we eliminate the final allocation that takes place when
we write out messages. Once again this was escaping to the heap, so we
make it an attribute on the Machine struct, which allows pure static
allocation.
```
goos: darwin
goarch: arm64
pkg: github.com/lightningnetwork/lnd/brontide
cpu: Apple M4 Max
BenchmarkWriteMessage-16 25840 46376 ns/op 2 B/op 0 allocs/op
BenchmarkWriteMessage-16 25646 46672 ns/op 2 B/op 0 allocs/op
BenchmarkWriteMessage-16 25874 46391 ns/op 2 B/op 0 allocs/op
BenchmarkWriteMessage-16 25512 46427 ns/op 2 B/op 0 allocs/op
BenchmarkWriteMessage-16 25760 46309 ns/op 2 B/op 0 allocs/op
BenchmarkWriteMessage-16 25789 46520 ns/op 2 B/op 0 allocs/op
BenchmarkWriteMessage-16 25602 46619 ns/op 2 B/op 0 allocs/op
BenchmarkWriteMessage-16 25766 46464 ns/op 2 B/op 0 allocs/op
BenchmarkWriteMessage-16 25820 46487 ns/op 2 B/op 0 allocs/op
BenchmarkWriteMessage-16 25634 46553 ns/op 2 B/op 0 allocs/op
PASS
ok github.com/lightningnetwork/lnd/brontide 16.907s
```
In this commit, we update the itest to check for precedence of the
config addresses over the persisted addresses.
We did not check for address persistence after restart (without the
extraArgs `--externalip`) because in `lntest/node/config.goL300`,
`GenArg` by default sets the `--externalip` flag, which makes
the config addrs to always take precedence over the persisted
addrs, for the tests.
In this commit we stop using persisted address in LND's prev run.
This means addresses set using `externalip` will be used without
merging them with the ones from prev run. We will introduce the
condition to use persisted addresses in the next commit.
In order to help external components to query the custom records of a
channel we need to expose the remote peer pub key. We could look-up
custom records based on the funding outpoint, but that relation is
established when receiving the ChannelReady message. The external
components may query the AuxChanState before that message is received,
so let's make sure the peer pub key is also available.
This is the final step, we actually call the interface and either
provide or retrieve the custom features over the message. We also notify
the aux components when channel reestablish is received.
We now plug-in the aux channel negotiator to the server impl config. We
also provide it to the peer config as that's where it's needed in order
to inject custom records in the appropriate peer messages.
We introduce this new interface with the purpose of injecting and
handling custom records on the init message, and also notifying
external components when receiving the ChannelReady or
ChannelReestablish message.
We need to make sure the `ListPeers` to be robust against errors from
the `FlapCount` so this RPC won't fail due to no flap count info. Also
updated the itest to check this field.
Similar to how we handle `chanfitness.ErrChannelNotFound`, we now also
ignore the `ErrPeerNotFound`. This is needed as previously we will
always see the peer in the channel event store given it'd added when
connected. This is no longer the case as we only add the peer to the map
when the channel is added.
We rename `getPeerMonitor` to `getOrCreatePeerMonitor` for clarity - it
will now send an online event when the peer monitor is being created,
which means we will only start counting the peer as online when it has
opened a channel with us.
Version v1.4.3 has some important bugfixes. We bump both version
in the same go so we do not need to tag the kvdb package and the
latest version of will be used.
Introduce ConfirmationsUntilActive and ConfirmationHeight in
PendingChannelsResponse_PendingChannel. ConfirmationsUntilActive indicates
the remaining confirmations needed for the channel to become active. If the
funding transaction is unconfirmed, ConfirmationsUntilActive defaults to the
total required confirmations (NumConfsRequired). ConfirmationHeight records
the block height at which the funding transaction was first confirmed; if
unconfirmed, it will be 0.
Signed-off-by: Nishant Bansal <nishant.bansal.282003@gmail.com>
