Investigate sequencer init tree latency
- Dominant language
- Go
- Stars
- 3.7k
- Forks
- 465
- Avg merge
- 2d 16h
- Merged PRs (30d)
- 5
Description
I'm looking into why we are getting linear growth of sequencer latency without any changes in the number of leaves being sequenced. It looks like the only part of the sequencing process that is getting slower as the tree grows is `initMerkleTreeFromStorage` which makes sense, each subsequent run requires retrieving a larger and larger tree (or more accurately set of sub trees).
Originally I was confused as I thought there was persistent caching of subtrees but after looking at the code closer it looks like the existing caching only happens at the [storage.LogTreeTx level](https://github.com/google/trillian/blob/1ac84cfe7b132dc082290d4f0f7c323d552e842c/storage/mysql/log_storage.go#L235). This means that subsequent runs of the signer don't get the benefit of cached subtrees and have to go and build the cache again each time.
Is there a specific reason for not caching this information at a higher level? It seems like it'd be significantly faster to just retrieve whatever new stuff was generated since the last sequencing operation.
Contributor guide
Assessment
This issue has not been assessed yet.