In Rustler you can use resource/ResourceArc to pass a reference into Elixir code. The documentation is quite lacking, but you can look at this test.

If you want to have mutable resource, you must manually synchronise on the Rust side. E.g. you can use RwLock, or an rcu.

Beware, that resource references cannot be shared across nodes AFAIK.

Resource references can be shared across nodes, but they can only be used (in a NIF) on the node that created them initially and only if it’s still alive when accessed. E.g. if you generate a resource object on your node from a process, send it to another node, let the process die and receive the answer back, the resource object will not “work” anymore.

I’m currently working on refactoring resources (and now that you say it, @cpud36, the docs for this one are indeed very much lacking) as they are using a mechanism that will produce warnings and later errors in rustc.

Data is always passed by reference into NIFs as they run in the same process environment as the calling process. You could (as an alternative to using a resource object) also store the data in a binary object (e.g. using something like flatbuffers). If it’s larger than 64 bytes, its data will not be stored directly in the process environment and will not be copied either.

Matches my understanding. Thank you for clarification.

I appreciate your work on the crate, and I had successfully used it just by looking at the signatures. Thank you.

I am willing to improve the docs once I find some free time. Is it ok to send a draft PR, so you can review for correctness?

Do you have an idea what is your current bottleneck? There are a several things you can do improve performance.

First, you can move business logic from GenServer into the callers. The idea is to serialise your HashSet into binary, and on request send relevant HashSet into caller. This is free since (large?) binaries are shared between processes. You can optimise even further and read ets directly from the caller, not sure though how well it performs. Computing in the caller processes will help utilising multiple cores of the cpu and reduce contention.

Second, you can optimise speed of your business logic. Either in elixir land, or by moving parts/all business logic into rust routines.

And lastly, if you still have a lot of contention on GenServer mailbox (after first idea), you can replace the whole ets table with rust object. You then wrap the rust object into a resource and just pass this reference around instead of GenServer. But my hunch is that ets is already doing sensible things, so you will not gain much without fancy concurrent data structures on the rust side.

Can you batch those?

Also, how large are your HashSets? 10k-100k, or more?

True enough, and I said the same thing above – haven’t benchmarked either, the only thing I’d predict as a clear win would be that the Rust solution wouldn’t copy data around (I think). But indeed it has to be checked.

To OP: cachex or ane might also be what you need. ane in particular makes a special effort to not copy on cache hits, and to be faster even than raw ETS.

My Rust chops have eroded a little bit since I haven’t used it actively in like half a year now but last I remember I have used DashMap successfully before in an application that had a very heavy usage of read and write caching. It’s single-node.

Sadly this was predating the times I became obsessed with telemetry so no clue if it’s doing better than ETS but I’d think since it doesn’t copy data that it should be faster.

Others have already pointed you at how you can create a resource inside the Rust code and return a reference to it in Elixir.