-
Notifications
You must be signed in to change notification settings - Fork 99
refactor: ntx builder start up #1610
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
Changes from all commits
bbe4d47
9e73beb
85e88c4
c21c34a
7f5dc11
10fef24
18f792c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -68,6 +68,9 @@ pub struct NtxBuilderConfig { | |
| )] | ||
| pub ticker_interval: Duration, | ||
|
|
||
| /// Number of note scripts to cache locally. | ||
| /// | ||
| /// Note scripts not in cache must first be retrieved from the store. | ||
| #[arg( | ||
| long = "ntx-builder.script-cache-size", | ||
| env = ENV_NTX_SCRIPT_CACHE_SIZE, | ||
|
|
@@ -77,6 +80,20 @@ pub struct NtxBuilderConfig { | |
| pub script_cache_size: NonZeroUsize, | ||
| } | ||
|
|
||
| impl NtxBuilderConfig { | ||
| /// Converts this CLI config into the ntx-builder's internal config. | ||
| pub fn into_builder_config( | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Bit confusing with the stuttering builder/builder naming, but that's not this PRs fault. We should come up with something better than network transaction builder.. Maybe network transaction..
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, I agree. We tend to use a lot the builder pattern so it is a bit confusing. I like both "producer" and "service", and even "consumer". I'll create a separate issue to discuss and rename the component since it touches too many files for this PR
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I opened #1620 |
||
| self, | ||
| store_url: Url, | ||
| block_producer_url: Url, | ||
| validator_url: Url, | ||
| ) -> miden_node_ntx_builder::NtxBuilderConfig { | ||
| miden_node_ntx_builder::NtxBuilderConfig::new(store_url, block_producer_url, validator_url) | ||
| .with_tx_prover_url(self.tx_prover_url) | ||
| .with_script_cache_size(self.script_cache_size) | ||
| } | ||
| } | ||
|
|
||
| /// Configuration for the Block Producer component | ||
| #[derive(clap::Args)] | ||
| pub struct BlockProducerConfig { | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is more a thought experiment, but I wonder if we ever want to set this to zero? Seems unlikely, but that would effectively be the same as disabling it.
I think
NonZerois used because that's what LRU requires, so we would have to dostruct MyLru<T>(Option<Lru<T>>)which is a bit more work but not too much.I kind of like the idea that we can disable caching e.g. for performance testing. wdyt? As a separate issue though, if anything. Could also easily be a YAGNI thing so maybe we just leave as is until we do need it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe to test performance of the underlaying implementation? Otherwise I don't see why we need that