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

Refactoring analysis: Executor prioritisation #58

Open
andresilva opened this issue Apr 26, 2022 · 2 comments
Open

Refactoring analysis: Executor prioritisation #58

andresilva opened this issue Apr 26, 2022 · 2 comments
Assignees
Labels
I4-refactor Code needs refactoring. I9-optimisation An enhancement to provide better overall performance in terms of time-to-completion for a task.

Comments

@andresilva
Copy link
Contributor

andresilva commented Apr 26, 2022

Analyse what kind of prioritisation we need (e.g. block authoring, off-chain workers, RPC calls) when sending requests to the executor. How is the implementation done in regards of prioritisation?

(will be updated with more details, mostly placeholder for planning/roadmap)

@koute
Copy link
Contributor

koute commented Apr 27, 2022

So I think this maybe could be split into two parts:

  1. Refactor and extend our low-level executor interface/cache which we use to instantiate a runtime and call into it with a given priority.
  2. Integrate it with higher-level APIs (which abstract over the low-level details of how we're calling into the runtime) and actually use it in specific places (block authoring, RPC calls, etc.)

The first part is also necessary for #57, since you need an asynchronous queue to prioritize executor invocations anyway. (So essentially the executor will be always asynchronous; it's just the non-async methods will call the async ones and block.) I was already planning on tackling this soon and I have some rough idea on how to go about it (as I've said at the very end of this comment paritytech/substrate#11232 (comment) and also this issue here is related paritytech/substrate#8846) so I don't think this part actually requires much planning.

I've also tagged this issue and the other one with the I7-optimisation tag since this might have performance implications (it might improve the performance since there will be potentially less blocking on the critical paths).

@koute koute added the I9-optimisation An enhancement to provide better overall performance in terms of time-to-completion for a task. label Apr 27, 2022
@bkchr
Copy link
Member

bkchr commented Apr 27, 2022

The first part is also necessary for #57, since you need an asynchronous queue to prioritize executor invocations anyway.

This issue is really more just about making runtime calls async. So you call call_in_runtime().await. That doesn't really require prioritization.

also this issue here is related paritytech/substrate#8846

This issue is exactly something that we then can fix when we have some central component that owns the cache and the execution :)

And in general good that you already had thought about this stuff, as I had this planed for you :D

@the-right-joyce the-right-joyce transferred this issue from paritytech/substrate Aug 24, 2023
@the-right-joyce the-right-joyce added I4-refactor Code needs refactoring. and removed I7-refactor labels Aug 25, 2023
jonathanudd pushed a commit to jonathanudd/polkadot-sdk that referenced this issue Apr 10, 2024
* renamed to-be-generic files

* make everything required generic over source/target chains

* some more fixes

* cargo fmt --all

* trait functions -> trait constants

* cargo --fmt --all
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I4-refactor Code needs refactoring. I9-optimisation An enhancement to provide better overall performance in terms of time-to-completion for a task.
Projects
Status: backlog
Development

No branches or pull requests

4 participants