feat: move ZstdDictionary inside NippyJar and create a snapshot manager#5139
feat: move ZstdDictionary inside NippyJar and create a snapshot manager#5139
ZstdDictionary inside NippyJar and create a snapshot manager#5139Conversation
Codecov Report
... and 9 files with indirect coverage changes
Flags with carried forward coverage won't be shown. Click here to find out more.
|
| let tx_range = ProviderFactory::new(open_db_read_only(db_path, log_level)?, chain.clone()) | ||
| .provider()? | ||
| .transaction_range_by_block_range(block_range)?; | ||
| .transaction_range_by_block_range(block_range.clone())?; | ||
|
|
||
| let mut row_indexes = tx_range.clone().collect::<Vec<_>>(); | ||
|
|
||
| let (provider, decompressors) = self.prepare_jar_provider(&mut jar, &mut dictionaries)?; | ||
| let mut cursor = if !decompressors.is_empty() { | ||
| provider.cursor_with_decompressors(decompressors) | ||
| } else { | ||
| provider.cursor() | ||
| }; | ||
| let path = SnapshotSegment::Receipts.filename_with_configuration( | ||
| filters, | ||
| compression, | ||
| &block_range, | ||
| ); |
There was a problem hiding this comment.
nit: I think we can avoid cloning by initializing path first, and then passing block_range by value into transaction_range_by_block_range
| pub struct SnapshotProvider { | ||
| /// Maintains a map which allows for concurrent access to different `NippyJars`, over different | ||
| /// segments and ranges. | ||
| map: DashMap<(BlockNumber, SnapshotSegment), NippyJar<SegmentHeader>>, |
There was a problem hiding this comment.
nit: I think it will be more intuitive to have a block range as a key, because currently this key means a snapshot for key..key+SNAPSHOT_BLOCK_NUMBER_CHUNKS
shekhirin
left a comment
There was a problem hiding this comment.
A few nits, otherwise LGTM! Code looks clean
…anager (#5139) Co-authored-by: Alexey Shekhirin <a.shekhirin@gmail.com>
NippyJar.ZstdDecompressorby using a reference from theZstdDictionary, without having to recreate the decompressor over and over. Not quite successful (ffi C reference, self-referential structs), might give it another go (with'static) in another time, but i feel like I spent too much time on it already.SnapshotProviderbasically becomes a snapshot manager which creates/loadsSnapshotJarProviderby reference.NippyJarhas been loaded once, it just gives a reference (usingdashmapfor the concurrent access map, but maybe rolling out its own arc<hashmap<key, rwlock>> might be better?SnapshotSegmentsto make it easily usable. (wrt config and filenames)