Skip to content
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

Optimize hash calculation #1599

Closed

Conversation

liudi4046
Copy link
Collaborator

Optimize function extractTransactionsFromSlot and sequencingBatchStep with Goroutine

Copy link

cla-bot bot commented Jan 6, 2025

Thank you for your pull request and welcome to our community. We could not parse the GitHub identity of the following contributors: Steven LIU.
This is most likely caused by a git client misconfiguration; please make sure to:

  1. check if your git client is configured with an email to sign commits git config --list | grep email
  2. If not, set it up using git config --global user.email [email protected]
  3. Make sure that the git commit email is configured in your GitHub account settings, see https://github.com/settings/emails

@liudi4046 liudi4046 force-pushed the steven/optimize-hash-calculation branch from a2327be to ec7c796 Compare January 6, 2025 09:13
Copy link

cla-bot bot commented Jan 6, 2025

We require contributors/corporates @liudi4046 to read our Contributor License Agreement, please check the Individual CLA document/Corporate CLA document

@hexoscott
Copy link
Collaborator

Thank you for the PR @liudi4046. There are a few other things going on in parallel to this:

  • checking if we need the transaction hash on the "happy path" at all. If not we can simply remove this and only call it when we need it for a log for example
  • parallel sender calculation - this we're looking to make some changes to as it degrades performance calling this repeatedly for many transactions so we shouldn't need to parallelise this once we have made these changes.

Let's keep this active for now until these points above have been resolved and if still needed we can address the updates and merge at that time.

@IvanBelyakoff
Copy link
Collaborator

Closing it as no actual performance gain for hash calculation #1603
Sender recovery improvement implemented in #1636

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants