And yes if you have something in memory is likely the same or faster when using a hashmap, but performance isn’t a one dimensional thing like comparing btree to hashmap performance. It’s the entire system as a whole. For instance, the binary note format is cpu cache friendly. Even just switching to that in damus ios helped perf immensely.

A lot of the computational things involved in note processing is amortized by having it done up front in the nostrdb and stored forever. Things like note content parsing (contents are chopped up into blocks, these are just offsets into the contents tagged with a type (url, hashtag, etc), stat counting, etc. i’m also going to add and store minimal perfect hashmaps for efficient mute word checking.

Just having these data structures near the note in memory and available to any app without duplicate processing was another motivation.

notedeck is a realtime system, i can’t have it do any work on the render thread. The render path has to be as fast as possible, it has forced me to move all of the computational upfront work into the nostrdb ingester pool.

This results in a smooth scrolling experience because the render thread is just accessing pointers to data that has already been processed.

Anyway, just trying to point out that hyper fixating on one component of the system would be misleading, as it was specifically designed for performance at every level.

If you want to check performance just run notedeck, you will see the results.