4 ms·

Author here. Agreed. We have some facility for out of process caching (node local memcached), and I frequently have to argue with colleagues that it's generall

• hinkley 2y ago
  I accept that it is true but I bristle at the fact of it. It shouldn’t be true.
  • byroot 2y ago
    Depends, it's not just about access time and GC pressure, it's also about sharing that cache with other processes on the node.
• foobazgt 2y ago
  A similar strategy is to serialize the object and store it in-process but off heap. This is useful when the values are private to the process, and/or they don't need to survive a crash, and/or you need to avoid the network overhead. Access times are often 100x-1000x faster.
  • kgeist 2y ago
    This is something I've been thinking about for a while. What if we create a language where all object references are explicitly specified to be either request-scoped or application-scoped. Don't allow application-scoped objects reference request-scoped objects. Allow to manually upgrade a reference from request-scoped to application-scoped if needed. That would allow us to have ephemeral per-request heaps which are torn down after every request at once. In-request garbage collections are super-fast. Application-scoped objects are never collected (i.e. no major collections). Wouldn't this simple model solve most problems? Basically, a very simple equivalent to Rust's lifetimes tailored to web services without all the complexity, and much less GC overhead than in traditional GC systems.
    • JonChesterfield 2y ago
      You could call them "arenas" to be consistent with the prior art. Yes, if you can partition the heaps into ones with distinct lifetimes, good plan.
    • ryukoposting 2y ago
      Given that Rust seems to be the generalized solution to this problem, would a viable prototype just be a Rust HTTP server with a Ruby interpreter embedded in it? Write the code in some kind of Ruby DSL which then feeds back into Rust? I ask because I have embedded Ruby in applications before, and I'm looking for an excuse to do it in Rust.
    • jnwatson 2y ago
      "What if we create a language where all object references are explicitly specified to be either request-scoped or application-scoped." I've done this in both C and C++. The downside of automatic memory management is you have to accept the decisions the memory manager makes. Still, generational GC like in Ruby and Python essentially attempts to discern the lifetime of allocations, and it gets it right most of the time.