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.
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.
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 great to see his open-source creations, like:
- a Redis like cache purpose built for real-time spatial locations: https://tile38.com/
- go package for reading JSON: https://github.com/tidwall/gjson
Glad to bring another one into this world.
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
Thanks you for the blog post about TG when it came out.
Supporting HTTP, Redis and PostgreSQL protocols at the same time is a neat trick!
The protocols are autodetected. No need to carry multiple ports around.
The README doesn’t seem to explain _why_ it is faster. Is it just highly hand-optimized? Is there some main technique used?
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.
Congrats on launching! Was following along with the development, glad to see it launched
Thanks Steve. Your feedback was very helpful.
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
Is the name related to Tadej Pogacar?
Hah I had the same question! Thought the project was aptly named if referring to the cycling champ if that’s what it was meant to be.
+1
No
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?
Genuinely curious, great project! Starred!
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.
Reminds me of this dope lib https://pythonhosted.org/johnny-cache/
Oh wow. That is dope. Thanks for sharing.
Congrats! Would you mind sharing what part of the design makes this faster than the competitors?
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.
Very interesting. Like the idea of using http, redis, or even PostgreSQL clients.
Is there a way to provide the auth password via an envar instead of a command line arg?
That's the only way right now. The other ways I'm considering is with an environment variable and/or acl.
May I suggest the ability to specific a path to a file that it is then read from.
Like an ACL file?
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.
very nice
What is nice about it? You have 9 comments over 3.5 years and they are all promoting your chat bot start up.
Thanks!