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.

Sign up for GitHub

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

Jump to bottom

(OTS) Garbage Collection Efficiency #880

Open
l-monninger opened this issue Nov 20, 2024 · 4 comments
Open

(OTS) Garbage Collection Efficiency #880

l-monninger opened this issue Nov 20, 2024 · 4 comments
Assignees
@mzabaluev
Labels
Source: Audit Issues discovered by audit. suzuka:performance

Comments

@l-monninger
Copy link
Collaborator

l-monninger commented Nov 20, 2024 •
edited
Loading

Summary

Each tick of mempool GC will only clear a single entry, which might make GC very inefficient. The if let Some(...) here probably needs to be a while let Some (...).
@l-monninger
Copy link
Collaborator Author

There is a longer debate also about the RocksDB ops too: #413, #628 (usage of DeleteRange) in particular.

@l-monninger l-monninger added Source: Audit Issues discovered by audit. suzuka:performance labels Nov 20, 2024
@l-monninger
Copy link
Collaborator Author

@khokho

@mzabaluev
Copy link
Collaborator

Oh, this is embarrassing.

@mzabaluev
Copy link
Collaborator

Will fix together with #879 since the whole approach has been rendered invalid by introducing another prefix layer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mzabaluev mzabaluev

Labels
Source: Audit Issues discovered by audit. suzuka:performance
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@mzabaluev @l-monninger