Stream: beginners

Topic: In-Memory Cache


view this post on Zulip Bryce Miller (Jun 08 2026 at 22:09):

Suppose I want to implement an in-memory cache for an append-only DB table. I might pre-populate it at startup, but after that it will query the database for a value after checking a hashmap, updating the hashmap if the value is found.

Is there a way to do this in pure Roc without a bunch of cloning? My understanding is that I'd need to keep the refcount at 1, and I'm not sure how easy/hard that would be. Would it be more straightforward or otherwise better to implement this in the platform host?

Context:

I need a mapping of account numbers, inventory locations, etc. to TigerBeetle Account IDs (128-bit int). My plan was to create an entry in postgres every time we add an account with appropriate metadata. However, we'd need to cache those mappings in memory to avoid bottlenecking TigerBeetle.

view this post on Zulip Bryce Miller (Jun 08 2026 at 22:11):

Additional context: This would be in a web server platform, so potentially multiple request handlers would need access to the cache simultaneously.

view this post on Zulip Luke Boswell (Jun 08 2026 at 22:59):

In basic-webserver we integrated Sqlite for in-memory storage, so that is something the platform provides. (It hasn't been ported to the new zig compiler yet though so there isn't a release or demo I can give you).

view this post on Zulip Bryce Miller (Jun 08 2026 at 23:44):

Yeah, SQLite could work too. I guess my main question is whether it's possible to do this in pure Roc (efficiently) or whether it needs to be done by the platform

view this post on Zulip Luke Boswell (Jun 08 2026 at 23:47):

In pure Roc things like lists are reference counted in memory automatically (or you can manually Box also to heap allocate), so this is efficient for in-memory caching.

If you are wanting to have multiple threads or concurrency I think you will need to have the platform support the specific use case as it is very context dependent.

view this post on Zulip Bryce Miller (Jun 08 2026 at 23:49):

That makes sense. I totally forgot about Box. That would be my way to get a pointer to pass around :sweat_smile:

I was thinking I'd have a Dict of potentially tens of thousands of k,v pairs, so wanted to be sure to avoid copying

view this post on Zulip Luke Boswell (Jun 08 2026 at 23:51):

I feel like you will be able to pass a Dict around efficiently ... but I'm a bit fuzzy on the details

view this post on Zulip Luke Boswell (Jun 08 2026 at 23:53):

How you do that exactly to avoid copies is probably more advanced I guess. We talked previously about having tooling that can help you identify where a copy might happen in your code, but it was a long time ago and I can't remember much about it.

view this post on Zulip Brendan Hansknecht (Jun 09 2026 at 04:11):

Passing a Box Dict or a Dict is no different here except that Box is less convenient. Both with pass by pointer rather than coping (Dict just passes a pointer and two u64s instead of one pointer). Both will mutate in place if the refcount is one. Both will duplicate the entire underlying data if the data is mutated with more than 1 reference.

view this post on Zulip Brendan Hansknecht (Jun 09 2026 at 04:12):

I'm not sure the state of Box optimization in the zig compiler. But hopefully it would actually mutate in place.

view this post on Zulip Luke Boswell (Jun 09 2026 at 04:12):

Box is already implemented and working well as far as I know

view this post on Zulip Brendan Hansknecht (Jun 09 2026 at 04:14):

In the case above I think the muplte request handler requirement likely will lead to needing to rely on sqlite though. Otherwise you won't be able to update in place. I don't think basic webserver exposes any way to update globally shared state. With some sort of centralized command architecture you could do it.

view this post on Zulip Krzysztof Skowronek (Jun 09 2026 at 07:10):

Are there any plans for roc to have built in actors or at least something like atoms?

Just a thing to hold a state, you give a function to get a new state, and you can retrieve the state - thread safe would be amazing :)

view this post on Zulip Anton (Jun 09 2026 at 12:05):

I love actors, I think the plan was to keep those kinds of things on the platform side until we find a compelling reason why we should not do that.

view this post on Zulip Bryce Miller (Jun 09 2026 at 13:03):

It makes sense that it would need to be part of the platform via SQLite or something else since its basically shared mutable state.

Not sure how i forgot that a Dict was a pointer anyway but clearly it happened :sweat_smile::upside_down:

I think maybe I’ll need to study up a bit more on ref counting to get a better intuition for when the count increments/decrements

view this post on Zulip Richard Feldman (Jun 09 2026 at 13:16):

I think maybe I’ll need to study up a bit more on ref counting to get a better intuition for when the count increments/decrements

FYI, I'm planning to start implementing #off topic > New Perceus algorithm alternative just dropped soon, which should dramatically decrease the number of refcounts that are happening (no idea how long it will take to add though!)

view this post on Zulip Romain Lepert (Jun 11 2026 at 20:45):

Richard Feldman said:

I think maybe I’ll need to study up a bit more on ref counting to get a better intuition for when the count increments/decrements

FYI, I'm planning to start implementing #off topic > New Perceus algorithm alternative just dropped soon, which should dramatically decrease the number of refcounts that are happening (no idea how long it will take to add though!)

Is it already in :eyes: ?
https://github.com/roc-lang/roc/pull/9595
https://github.com/roc-lang/roc/pull/9604

view this post on Zulip Luke Boswell (Jun 11 2026 at 21:51):

Yes... :grinning_face_with_smiling_eyes:


Last updated: Jun 16 2026 at 16:19 UTC