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.
No, like a path to a file containing the secret/passphrase that the program can then read it from. I am not a fan of putting secrets directly into environment variables.
Environment variables are prone to leak or be passed to child processes when it is not desired. But if they are just a file path/pointer to where the secret is, that is mitigated somewhat as one then would still need access to that file.
Always excited to see Josh's projects - last time I played with uhaha (loved the name) and it was mind-opening to some extent. Pogocache also looks very interesting and good to see the benchmarks on ARM
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.
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.
- a Redis like cache purpose built for real-time spatial locations: https://tile38.com/
- go package for reading JSON: https://github.com/tidwall/gjson
Is there a way to provide the auth password via an envar instead of a command line arg?
Environment variables are prone to leak or be passed to child processes when it is not desired. But if they are just a file path/pointer to where the secret is, that is mitigated somewhat as one then would still need access to that file.
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!
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.