You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, whenever a value is retrieved from Paprika, a list of ancestors is walked through to find whether or not the given value can be provided by it. It's optimized as it uses Xor filter to check whether the given block can serve the read or not. Still, it requires a lot of reads because it always loops over:
private ReadOnlySpanOwnerWithMetadata<byte> TryGetAncestors(scoped in Key key,
scoped ReadOnlySpan<byte> keyWritten,ulong bloom)
{
ushort depth =1;
var destroyedHash = CommittedBlockState.GetDestroyedHash(key);
// walk all the blocks locally
foreach(var ancestor in _ancestors)
{
var owner = ancestor.TryGetLocal(key, keyWritten, bloom, destroyedHash,out var succeeded);
if(succeeded)
return owner.WithDepth(depth);
depth++;
}
return TryGetDatabase(key);
}
These reads could be sped up using various approaches.
Proposals
squashing the anscestors: when the block is created for processing, squash ancestors so that they can serve values fast (proposed by: @benaadams@LukaszRozmej)
use a Dictionary<ulong, ushort> which would map hash -> ancestor depth that would point to the first ancestor that has the hash set. This would be much easier and lighter to create. If no value for the given ulong, this means the db should be hit.
While the first approach would save lookups making them direct (one lookup against one value) the second could provide removal of Xor filters altogether or put Xor only on top of the map created in this way (this should be measured whether it's worth it)
The text was updated successfully, but these errors were encountered:
Currently, whenever a value is retrieved from Paprika, a list of ancestors is walked through to find whether or not the given value can be provided by it. It's optimized as it uses Xor filter to check whether the given block can serve the read or not. Still, it requires a lot of reads because it always loops over:
Paprika/src/Paprika/Chain/Blockchain.cs
Lines 1037 to 1055 in 0b36ee9
These reads could be sped up using various approaches.
Proposals
Dictionary<ulong, ushort>
which would maphash -> ancestor depth
that would point to the first ancestor that has the hash set. This would be much easier and lighter to create. If no value for the given ulong, this means the db should be hit.While the first approach would save lookups making them direct (one lookup against one value) the second could provide removal of
Xor
filters altogether or put Xor only on top of the map created in this way (this should be measured whether it's worth it)The text was updated successfully, but these errors were encountered: