4 ms·

That's aggressively missing the point. If you design the program architecture around manual memory techniques, the runtimes are stable even in a GC. If you use

• jstimpfle 10y ago
  But my point was simply that you can't defend GC by contrasting to manual management, if you do manual management. > If you use malloc willy-nilly throughout core algorithms, your runtimes become unpredictable. First, where did I say "use malloc willy-nilly"? Second, do you have experience with that? I haven't much, but I haven't heard your claim before. Of course "willy-nilly" should not be done with real-time constraints. But I have written a substantial algorithmic program (no RT constraints) in that style when I didn't know better, and it was very well performing. (probably glibc's malloc was optimized for my allocation patterns). The main problem I see with that style is that each malloc has memory overhead, and that it leads to unmaintainable code.
  • Kenji 10y ago
    Actually, to address realtime constraints... In my job, I work on systems with realtime constraints and even in less critical parts (latency of ~100 microseconds is still acceptable) we had to eliminate all malloc calls. Mostly because malloc on our platform essentially acquires one big lock for memory operations and if some other process has that lock, you get nasty delays or even priority inversions. Allocate a big chunk beforehand, preferrably in the form of ring buffers, and then operate on these if you need precise timing and performance.
    • jstimpfle 10y ago
      ... or use a version of malloc on that preallocated thread-local chunk. At least if the only problem is locking overhead.