WIP: Speedup search, part 3: don't allocate while searching for attributes #1687
No reviewers
TrueCloudLab/storage-core-committers
TrueCloudLab/storage-core-developers
Labels
No labels
P0
P1
P2
P3
badger
frostfs-adm
frostfs-cli
frostfs-ir
frostfs-lens
frostfs-node
good first issue
triage
Infrastructure
blocked
bug
config
discussion
documentation
duplicate
enhancement
go
help wanted
internal
invalid
kludge
observability
perfomance
question
refactoring
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: TrueCloudLab/frostfs-node#1687
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "fyrchik/frostfs-node:speedup-search-3"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR implements (3) suggestion from #1685.
Please, review the second commit only.
There is a noticeable improvement, but I don't want our metabase to become new tree service.
I have tried to compress the code as much as possible and make it easy to validate.
The main purpose of this PR is to discuss whether we want to go for such optimizations at all.
This PR depends on #1686.
Comparison with #1686:
@ -136,0 +135,4 @@
if err != nil {
return nil, err
}
return par.Marshal()
This is bad, it will be fixed, of course.
We can do much better
What bothers me is that this new code should also do marshaling, because we
Parent()
method on child reassembles object from fields in its split header.On the other hand, we only need header in SEARCH, so we might avoid marshaling at the cost of making
getRaw
more complex.Speedup search, part 3: don't allocate while searching for attributesto WIP: Speedup search, part 3: don't allocate while searching for attributesaac2449d49
to1ec5377241
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.