Skip to content

Epoch processing performance optimizations #1399

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
rodrigo-o opened this issue Mar 19, 2025 · 1 comment
Open

Epoch processing performance optimizations #1399

rodrigo-o opened this issue Mar 19, 2025 · 1 comment
Labels
perf performance-related PRs or issues

Comments

@rodrigo-o
Copy link
Collaborator

After some work on reducing slot processing time, which greatly enhance block processing we still have a big bottleneck on every epoch processing. After some measures I was able to pinpoint the specific part of the code were 95% of the time was taken in the epoch processing execution and it was in a particular zip operation under rewards and penalties calculation as show by the following logs:

Image

This could be found here, but the line was modified to an Enum.zip instead of Stream, to be able to measure the bottleneck.

Something more caught my eyes when following the logs, there were 3 things that could be potential candidates for performance optimizations:

  1. I'm not completely sure but as far as the log shows, epoch processing occurs more than once within 3/4 blocks of difference instead of happening once every 32 blocks, there might be something involved related to the triggering of the epoch processing
  2. committee prefetch happens more than once nearly at the dame time due to the cache not storing the previous process calculating it in the meantime
  3. slot processing recalculates block and state root due to them not being available which apparently just happens near the epoch processing as shown in these logs

Image

This could easily become an umbrella Issue with sub task for tackling the aforementioned discoveries one at a time.

@rodrigo-o rodrigo-o added the perf performance-related PRs or issues label Mar 19, 2025
@rodrigo-o
Copy link
Collaborator Author

After spending some time looking at the bottleneck, I saw it happened in the Enum.zip due to it receiving a stream of deltas, so most of the time was spent on get_flag_index_deltas, particularly in the pre compute base rewards for all validators.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
perf performance-related PRs or issues
Projects
Status: No status
Development

No branches or pull requests

1 participant