Hey @rabbithole, thanks for the kind words.
Concerning this lib, I do not advise using it for the following reasons:
- It has a good test coverage but still, I don’t think much people are using it (which is a bit of a red flag to me). And I know @skilesare had an issue once with initializing a btree with nodes of size of 1024kb, I don’t know if he gave up using the lib or not.
- The usage is a bit hard: right now you need to keep memoryIds of the memory chunks allocated for your btrees. Also if you use it as is, you’re gonna be bound to use the MemoryManager that comes with it, so if in a potential next version the memory Region are used instead, you won’t be able to upgrade your btrees using the memoryManager to the one using the regions.
- There’s probably a better alternative out there, the stable map version from @ZhenyaUsenko : GitHub - ZhenyaUsenko/motoko-hash-map: Stable hash maps for Motoko but I’m not quite sure if it fits your need. I think at least in theory btree shall work better to store big blobs? I haven’t done any benchmark myself to compare the performance between the stable btree and this motoko-hash-map for example, so I couldn’t say.
- At the end I don’t have the time right now to work on it to use the new memory regions myself. But it would be nice to have it implemented someday indeed.
Concerning the changes on the branch you’re pointing to they were meant to increase the speed at which the functions are executed (by avoiding uncessary conversions between blob and [nat8] done when reading/writing in stable memory). I don’t think it reduces much the size of the data stored in the btree. I might be wrong, I don’t know what is the size of a blob compared to a [Nat8] in memory.