This makes a small difference for NetworkGraph deserialization
as it enables more inlining across different files, hopefully
better matching user performance as well.
As of this commit, on an Intel 2687W v3, the serialization
benchmarks take:
test routing::network_graph::benches::read_network_graph ... bench: 2,037,875,071 ns/iter (+/- 760,370)
test routing::network_graph::benches::write_network_graph ... bench: 320,561,557 ns/iter (+/- 176,343)
Other includes calling timer_chan_freshness_every_minute() and in the
future, possibly persisting channel graph data.
This struct is suitable for things that need to happen periodically and
can happen in the background.
Defines an interface and related types for fetching block headers and
data from a block source (e.g., Bitcoin Core). Used to keep lightning in
sync with chain activity.
Intended to be a cross-platform implementation of the
channelmonitor::Persist trait.
This adds a new lightning-persister crate, that uses the
newly exposed lightning crate's test utilities.
Notably, this crate is pretty small right now. However, due to
future plans to add more data persistence (e.g. persisting the
ChannelManager, etc) and a desire to avoid pulling in filesystem
usage into the core lightning package, it is best for it to be
separated out.
Note: Windows necessitates the use of OpenOptions with the `write`
permission enabled to `sync_all` on a newly opened channel's
data file.
In 9e03087d6a we started setting
`opt-level` only on profile.test and not profile.dev. When that
commit was authored I tested only that rustc was being called with
opt-level set in its flags, not that the resulted run ran at the
speed I expected. It seems profile.test isn't applied properly to
dependencies or so, resulting in tests running much slower than
they do at profile.dev.opt-level=1.
Until we get the bindings generation process super stable, let the
bindings get stale with respect to the main repo while still letting
`cargo check` pass.
Implement error, warn, info, debug and trace macros, internally calling
an instance of Logger, and passing it to every main structures
Build-time or client-side filtering.
Issue #54
Sadly none of them are really any good without some hand-holding to
generate good input data, and unless sha256 gets stubbed out I'm
not sure they're gonna get good without a symbolic execution fuzzer
