Michal Nazarewicz

> What I'd suggest - is having a metric that measures the time between our 'log_summary' runs. Sounds like a counter incremented at the start of log_summary.

I don’t recall working on tests but this may be related to https://github.com/near/nearcore/issues/3266

Question can also be asked whether we should just `assert`. To me, `debug_assert` makes sense in hot paths or generally when checking the condition is too expensive for production code.

I’m not sure it’s as simple as replacing all debug_asserts with logging on non-debug builds. For example: ``` chain/chain/src/chain.rs:300: debug_assert!(_visited.insert(*hash)); ``` should stay as debug_assert I think because the cost...

What’s the idea here actually? Is it better phrased as ‘password-protect secret keys’? Or we could go all the way an go with some kind of GPG support so that...

> Once rolling this, we will need to update nearup first to use the same RUST_LOG env var, as it depends still on this flag to pass custom logging parameters....

LGTM

I’ve run store-validator against one of the betanet nodes whose data is

Quick look indicates that the slowdown comes from the storage. I’ve added some more tracing and here’s output with a fast `process_transaction` invocation followed by a slow one (they are...

It doesn’t look like cache issues. I haven’t measured cache hit ratio or counted how often we hit the storage, but just by looking at logs the numbers seem similar...