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
⚠️ With fix(trie): remove encoding buffers pool #2929 and recent commits, the in-memory tries are no longer leaking memory, and it can clearly be seen our current database implementation leaks memory pretty bad and also uses 50% of our CPU usage, which is also bad.
having a separate repository for the database implementation (and interfaces) doesn't make sense now and probably won't in the future either.
Interfaces, constructors are oddly designed in the chaindb repository
chaindb uses a rather outdated and obscure fork of badgerdb
Prioritizing this issue right now, especially to see the result memory-usage-wise in order to take the right decision regarding state code changes (lazy loading, v1 state trie, other performance considerations).
The plan is to create an internal/database/badger package using badger/v3 with cleaner constructors and interfaces in the rest of the code, and remove the chaindb dependency. A very simple internal/database/memory package might be created as well to ensure we have the right interfaces for multiple implementations. More database implementations can be added later on if needed for different memory or CPU usage trade offs.
This is blocked by #2981 since our code is rather tightly coupled unfortunately when it comes to replacing the database.
The text was updated successfully, but these errors were encountered:
A few key points why this is needed:
Prioritizing this issue right now, especially to see the result memory-usage-wise in order to take the right decision regarding state code changes (lazy loading, v1 state trie, other performance considerations).
The plan is to create an
internal/database/badger
package usingbadger/v3
with cleaner constructors and interfaces in the rest of the code, and remove the chaindb dependency. A very simpleinternal/database/memory
package might be created as well to ensure we have the right interfaces for multiple implementations. More database implementations can be added later on if needed for different memory or CPU usage trade offs.This is blocked by #2981 since our code is rather tightly coupled unfortunately when it comes to replacing the database.
The text was updated successfully, but these errors were encountered: