Should `Agent` support hibernate

Chat / Discussions
,
1

I was reading the docs on Agent and noticed there is no mentions of hibernation at all.
Given that Agents are just wrappers around GenServers I was kinda surprised .

So I read through the code, but hibernate is not used at all.

Wouldn’t it make sense to support hibernate on Agent? I noticed that hibernation reduce memory consumption often a lot.

1 Like
2

You would think so, yep, but I’d say if you have enough Agents in memory that hibernating them would help you then you have a huge design problem. I mean, you would probably need 500K - 1M agents for this to make a tangible difference. And you absolutely should not have so many agents.

4 Likes
3

I find that a bit of a weird argument.

You can make the same argument for GenServers and LiveViews.
GenServers support hibernate and LiveView has a default hibernation after 15s.

1 Like
4

One more thing. It’s actually trivial to write an agent that grows huge in size if not hibernated and where hibernation makes it tiny again.

Agent.start_link(fn ->
  x = fetch_something_big()
  calculate_something_small_from(x)
end, name: :foo)

This will create a huge Agent named foo, although it might just have a tiny state.
After hibernation this would become tiny again.

You could of course trigger :erlang.garbage_collect on it manually to get the same result.

1 Like
5

Yes, but the idea of an Agent is not to fetch huge data in it. It’s for simple concurrent state management. You’d fetch the data and then update the Agent’s state. API’s should be hard to misuse.

1 Like
6

IMHO, Agent is just GenServer with training wheels. I moved to full GenServer for all Agents except the trivial ones. Maybe the core team think adding advanced features to a “training-wheel” API is not worth their time?

4 Likes
7

That’s not an idea I read in the docs.

The first function blocks the agent. The second function copies all the state to the client and then executes the operation in the client. One aspect to consider is whether the data is large enough to require processing in the server, at least initially, or small enough to be sent to the client cheaply. Another factor is whether the data needs to be processed atomically: getting the state and calling do_something_expensive(state) outside of the agent means that the agent’s state can be updated in the meantime. This is specially important in case of updates as computing the new state in the client rather than in the server can lead to race conditions if multiple clients are trying to update the same state to different values.
(from Agent — Elixir v1.17.3)

The docs say to consider if the data is large enough to require processing in the server.
It doesn’t say that you should not process large data in an agent.

Anyway, I don’t mind too much that Agent doesn’t have hibernate. I seem to be the first person missing this, and it’s easy enough to work around.

I was a bit surprised about it though, because it’s easy to have big stacks that can be a lot smaller after garbage collection. Anyway, it might not be an issue at all and might be cleaned up once garbage collections kicks in.

8

Completely agree, there is absolutely zero benefit from using an Agent over a Genserver besides those 2 callbacks that dump the state.

9

Another angle to consider is that I personally would reach for ETS if load and/or payload size(s) start growing.

1 Like
10

@tcoopman - Agent supports hibernate_after, I just tried and confirmed it works (using :observer I looked that the Processes → Current Function).

When you call Agent.start_link just pass in the hibernate_after option in miliseconds.

Looking at the code, Agent.start_link will pass through the options to GenServer.start_link

6 Likes