Mirror of forum.nim-lang.org

13245 :: Turning on ARC selectively?

• Haddock (orginal) [2025-07-23T11:36:12+02:00] view original

  helo,

  I just had a look at Nim some few days ago and like it quite much. I also like too look at D. In D by default the GC does the memory management, but you can overrule the GC by deregistering objects from the GC (then you have to deallocate it yourself) or you can switch to manual memory mangement by attaching a @nogc annotation to some method. That gave me the idea whether it would be possible or would be an idea to have something like an @arc annotation in Nim you can attach to some method. So by default the GC is turned on, but you can overrule it and stick to ARC in some method annotated with @arc. This you would do in case some piece of code runs slow with the GC.

  Just an idea ... Regards, Haddock

---

• Araq (orginal) [2025-07-23T15:54:19+02:00] view original

  Yeah well, we don't copy bad designs. If arc is too slow, learn how to use sink, cursor and lent annotations. Also use custom containers, Nim 2.0 is about memory management that composes well with custom containers.

---

• Haddock (orginal) [2025-07-23T16:58:33+02:00] view original

  Well, I guess I did not explain my question that well. I did not say that ARC is too slow. I was suggesting that when in certain cases the GC is too slow you can selectively revert to ARC. You would attach some annotation named @arc to some function and then the runtime for the execution of that function would resort to ARC instead of GC.

---

• PMunch (orginal) [2025-07-23T17:24:39+02:00] view original

  In Nim 2.0 it uses ARC with an extra cycle collector stage. If your data doesn't have cycles it probably won't trigger the cycle collector and therefore behave just like ARC. So I don't think there's much use for saying something is explicitly ARC (and we already have a pragma to tell that there can't be cycles).

---

• Haddock (orginal) [2025-07-23T18:59:04+02:00] view original

  Okay, from reading about memory management in Nim from this page https://nim-lang.org/1.4.8/gc.html I conclude that you have to define with a --gc flag whether to let one of the available GCs do >all< the memory management automatically or >everything< be ARC. My case is this: some application writen in Nim is started up using one of the available GCs. From now on >all< memory management is done be the selected GC. This is fine for the most part of that application except for some few functions that need to be especially efficient or more efficient than they are when using a GC.

  So the application is started up letting some GC do all the memory management work, but for those few functions that need to be especially efficient I can manage memory using ARC instead. By applying some annotation to those functions may called @arc the overhead caused by the GC no longer applies, but more eficient ARC is made use of. What do you think of this idea?

---

• Araq (orginal) [2025-07-23T19:22:47+02:00] view original

  A more up to date version of this document is here: https://nim-lang.org/2.2.0/mm.html

  In summary, your idea is based on an outdated mental model. Nim's default works well with custom containers and there is nothing to worry about as it's entirely modular: Optimize hotspots as required the rest of the runtime won't interfere with any stop-the-world or tracing mechanisms.

---