I thought I recognized the tidwall name - Josh is also responsible for tg which is a really neat, very tight C geospatial library: https://github.com/tidwall/tg
Yes, it is highly hand optimized. There's a description of some of the methods I used near the bottom of there README. I mainly focused on minimizing contention, with the sharded hashmap and such. But the networking layer is carefully crafted.
Thanks! The Pogocache sharded hashmap design is optimized for extremely low contention and good memory locality. It super rare for any two threads to ever wait on the same key. That's the biggest part and it's all in the src/pogocache.c file. But the network layer is finely tuned too.
Mostly I perfed and profiled ad nauseam, monitoring cpu cycles along the way. I found that keeping a focus on latency and cycles was primo, and the rest fell into place.
Really looks fascinating.. Might need a deeper dive.
Also.. like, it says that you plan on supporting sql? is this true? What does that actually mean really since I guess it might then compete with things like sqlite/duckdb?
Not intending to make pogocache into a sql database. I prefer keeping it a cache. More so exploring ways to work with existing databases such as sqlite, duckdb, postgres. Kinda like providing proxy-ish operations that transparently cache sql reads.
- a Redis like cache purpose built for real-time spatial locations: https://tile38.com/
- go package for reading JSON: https://github.com/tidwall/gjson
Mostly I perfed and profiled ad nauseam, monitoring cpu cycles along the way. I found that keeping a focus on latency and cycles was primo, and the rest fell into place.
Also.. like, it says that you plan on supporting sql? is this true? What does that actually mean really since I guess it might then compete with things like sqlite/duckdb?
Genuinely curious, great project! Starred!
Is there a way to provide the auth password via an envar instead of a command line arg?