I am not really into this memory allocation business (spoiled by the likes of Java and Swift), but what are we doing here? Why so many new versions? Why always so inspirational names? Can these even work with each other? Should we try to harmonise?
It’s not so important. The meaningful problems are bugs in spline routing, orthogonal edge routing, the “trouble in init_rank” that would not die, lack of object classes in the graph language, and one or two outstanding CERT advisories. That weird bug with ports on record nodes being flipped in certain left-to-right layouts Incrementally stable layout in dotgen, Can gvedit make the jump to QT6. New algorithms that could help with untangling hairballs. These are interesting topics.
Stephen, could you elaborate on “lack of object classes in the graph language”. What kind of classes? Do you mean like style attribute classes (like CSS classes) that are shorthand for a set of attributes?
Agree it’s not that important to reduce the number of mallocs used.
Vithanco, my background is mostly C/C++ and I still had a very similar reaction to you when learning the code base. In 2020 I deleted as much of lib/vmalloc as I could and tried to reduce other malloc duplication across the tree. Let me try to answer your questions…
Some of these have slightly different purposes. There’s the three library functions Mark noted, then the “g” prefixed wrappers that exit on failure and the “z” prefixed ones that return pre-zeroed memory. As for why the macros like N_NEW are repeated in various parts of the code base, I assume when this code was written #includes were somehow expensive and to be avoided.
My interpretation of the prefixes is “g/G” = “global”, “N_” = “new”, “z” = “zeroing”. This is terse, but pretty common in C code bases. I’ve seen the same named functions elsewhere.
Yes. They all allocate from the same heap, with the exception of lib/vmalloc (“vm” prefixed functions) which is an arena allocator. In the long term I would like to remove it completely.
Maybe. Some of these wrappers are useful. E.g. the zmalloc wrapper helps write more readable code. The “g” prefixed wrappers are also useful because many Graphviz allocations do not check the return value. None of this is really good practice, but we have to deal with the situation as it is.
I like that, @scnorth. That is exactly what I do with Vithanco. I create Node Types, and I even define which type can be connected to which other Node Types, hence I create a Meta model for my graph.
I found it very useful to have the Node Type name in the node, I use that in most meta models. Here an example from the Benefit Breakdown Structure (Domain)
I think that class syntax could really help for the usecase of technical graphs checked in to documentation. Some of it we can achieve with CSS on generated SVG but not all. We have the “class” attribute that we might want to reuse to avoid users naming their own attributes that might conflict with future attributes?