Mirror of forum.nim-lang.org

9491 :: To `ref` or not to `ref` on embedded?

• BarrOff25 (orginal) [2022-09-24T14:07:09+02:00] view original

  Hello

  I want to do some project on an arduino board. Writing some code I started thinking about whether using ref objects or not makes sense for embedded targets? What are the pros and cons of each option?

---

• auxym (orginal) [2022-09-24T18:46:11+02:00] view original

  Most people will avoid refs (and dynamic heap usage in general in embedded) because of the associated runtime cost, the difficulty in predicting memory usage on these constrained systems, and the risk of heap fragmentation.

  That said, use them sparingly if you have to, and you know the limits of your system. I don't mind using a seq or string here or there if I know there's an upper bound in size. Or even ref objects if you are building a recursive data structure like a graph or tree, but that's sort of rare in embedded.

  Prefer plain objects in general and only use refs if you really need them.

---

• arnetheduck (orginal) [2022-09-24T19:13:25+02:00] view original

  +1 - the simple advice is to never use ref object unless semantics demand it - then the caller can decide if they want a ref Type or not and type it out

---

• demotomohiro (orginal) [2022-09-24T19:36:38+02:00] view original

  I wrote about differences of 'ref object' and plain 'object' before: https://internet-of-tomohiro.netlify.app/nim/faq.en.html#type-when-to-use-ref-object-vs-plain-object-qmark

---

• elcritch (orginal) [2022-09-25T06:04:52+02:00] view original

  I've used ref objects on embedded and it can be fine and very convenient even. Prefer a acyclic with ARC. Partly though it depends on how much RAM you have. Here's some rules of thumb I've found:

  • <16kB of free ram use very sparingly
    • the allocator means you'll only be able to use a small number of ref objects at a time

  . * a single string can kill half your ram due to fragmentation

  • ~32kB free ram and you don't need to worry too much

    • you can mostly use stdlib functions
    • still better to be spairing

  • >= 64kB you can do most basic things

    • run async things, etc
    • I've never had issues with fragmentation with 64kB or more of RAM

  Now aside from free memory space it's good to remember that allocations are expensive. Very expensive on embedded, and not something you'll want in any sort of loop.

  My general guidance would be to limit ref objects to long lived configuration objects and containers. Allocate containers outside any loops and be careful of copies.

  Usually the best performance can be found by getting in the habit of using var in proc arguments for arrays or struct. Using var openArray[T] with T being non-ref objects generally gives good performance. Ref objects can be useful if you can't use var due to code constraints.

---

• Stefan_Salewski (orginal) [2022-09-25T09:28:26+02:00] view original

  Usually the best performance can be found by getting in the habit of using var in proc arguments for arrays or struct. Using var openArray[T] with T being non-ref objects generally gives good performance. Ref objects can be useful if you can't use var due to code constraints.

  Advertising the use of var proc parameters for performance reasons is very strange. The compiler is advertised to pass value data with size larger than 3 * sizeof(float) as a hidden pointer to procs, so use of a var keyword should make only a minimal performance difference. And note that there is currently no struct data type in the Nim language :-)

---