1. 14
  1.  

  2. 9

    A few words of warning if you want to use ETS:

    • ETS tables go away if the process dies. To get around this (if you need to) set a heir when creating, or call give_away to transfer ownership.
    • As mentioned in the article, ETS tables don’t have the same GC rules as the rest of Erlang’s managed memory. You need to call delete or terminate the owning process to get the space back.
    • If you need a lot of them, tweak ERL_MAX_ETS_TABLES. By default you get 1400.
    • If you need to dump to disk DETS has its own special brand of rules.
    • Everything in the “Tables and Databases” also applies.
    1. 2

      It seems to me that the punchline here is “you can get way better latency for this many-long-lived-objects case by moving them off the heap”, in this case into ETS. Given the simplicity of the use case described for Pusher (only integer keys, only bytestring values, persistence not really needed), I’m wondering if they’d have benefited from trying that too. Say, FFI binding to a mutable data structure in C or whatever.