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.

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

LRU cache #74

Open
Stebalien opened this issue Sep 12, 2018 · 3 comments
Open

LRU cache #74

Stebalien opened this issue Sep 12, 2018 · 3 comments
Labels
kind/enhancement A net-new feature or improvement to an existing feature topic/perf Performance

Comments

@Stebalien
Copy link
Member

Now that we have nice, string-backed CIDs, we should consider caching them in an LRU cache. My hypothesis is that, when working with CIDs, we likely regenerate them several times. For example, with bitswap, we'll re-create the CIDs when we receive the blocks we're looking for. When we do this, we may end up storing each CID in memory twice.

Note: we'll have to be very careful with this. This is the kind of optimization that could end up hurting performance (or even memory usage) more than it helps if we're not careful. It may not even be worth it in practice.

@Stebalien Stebalien added kind/enhancement A net-new feature or improvement to an existing feature topic/perf Performance labels Sep 12, 2018
@kevina
Copy link
Contributor

kevina commented Sep 22, 2018

Note: we'll have to be very careful with this. This is the kind of optimization that could end up hurting performance (or even memory usage) more than it helps if we're not careful. It may not even be worth it in practice.

Since CID are fairly small my instincts are telling me that this will be more trouble then it's worth and is unlikely to improve memory enough to be worth it.

@Stebalien
Copy link
Member Author

You're probably right. We probably do store duplicate CIDs at points however most of these are likely ephemeral. All of our caches tend to work with blocks from disk so they'll all use the same CID from the same memory location.

@Stebalien
Copy link
Member Author

(but it shouldn't be difficult to investigate this)

@momack2 momack2 added this to Inbox in ipfs/go-ipfs May 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement A net-new feature or improvement to an existing feature topic/perf Performance
Projects
No open projects
Development

No branches or pull requests

2 participants