Mirror of forum.nim-lang.org

2294 :: Nested procs, closures. Heap allocation: when?

• mbaulch (orginal) [2016-06-01T11:53:38+02:00] view original

  According to the manual, anonymous (or otherwise) nested procs become closures if they "access local variables from their enclosing scope". In particular,

  The closure environment may be allocated on the heap or on the stack if the compiler determines that this would be safe.

  which worries me a little. When writing performance sensitive code, it's important to know more than "may be allocated ... on the stack". Digging into the compiler source at genClosureCall (in ccgcalls.nim), it seems that the closure environment is stack allocated when the proc returns:

  • Nothing, or
  • Some type T for which isInvalidReturnType (in ccgtypes.nim) returns true

  To illustrate, for instance, in the code:

  proc f(p: proc()) = p()
  
  var a = 1
  f do ():
      var b = 2
      f do ():
          var c = 3
          let d = a + b + c
  Run

  I'd assume no heap allocations occur.

  Is it simply the nested proc's return type, as described above, that determine's whether variables are heap or stack allocated? If that's so, I'm sure we could write a straight-forward rule for such situations. Maybe it should be added to the manual? Surely there are others who wonder about the performance properties of closures.

---

• Araq (orginal) [2016-06-01T12:47:16+02:00] view original

  Your reading of the compiler's implementation seems to be wrong. In the current implementation every closure that actually captures something is put on the heap, unused closures don't allocate (the environment pointer is nil then). So no need to be concerned: When writing performance sensitive code, don't use closures. ;-) In nearly all cases where the closure doesn't escape and can be put on the stack in theory, a Nim template does the job too. And a template also guarantees inlining.

---

• mbaulch (orginal) [2016-06-01T13:39:31+02:00] view original

  Okay. A closure call causes a heap allocation only if a variable capture occurs. Thanks for the clarification.

  Closures are a bit more flexible than templates where overloading (see here) is concerned. Though you're right: templates provide strong guarantees. I'll focus in that direction.

  Thinking about the difficulties of a C backend, it seems this is a situation where more flexible calling conventions would help. An LLVM backend, perhaps? I'd be very sorry to lose Nim's amazing C and C++ interfacing, though.

---