Also, now the times I get on that same machine (with no window system running,
no services, but I did not do isolcpus or taskset or chrt which might help
lower noise) looks like: gc:arc (release or danger):
min(10)Worst(1000000): 3181.519 +- 178.596 ns
min(5)min(10)Worst(1000000): 2972.428 ns
[GC] total memory: 31936512
[GC] occupied memory: 14048
Child user: 1.257 s
Child sys : 0.011 s
Child wall: 1.271 s
Child high-water RSS : 32.8 MiB
Run
Note only 5.6% variation on the min's suggests (but can only prove an upper
bound) that the new worst case is about 3 microseconds.
The old collector with `-d:useRealTimeGC` and _not_ disabling the mark and
sweep (which blows up mem usage) gets:
min(10)Worst(1000000): 264217.609 +- 3735.044 ns
min(5)min(10)Worst(1000000): 260037.178 ns
[GC] total memory: 54321152
[GC] occupied memory: 34427360
[GC] stack scans: 5502
[GC] stack cells: 26
[GC] cycle collections: 3
[GC] max threshold: 36357728
[GC] zct capacity: 39366
[GC] max cycle table size: 0
[GC] max pause time [ms]: 0
[GC] max stack size: 1104
Child user: 1.768 s
Child sys : 0.012 s
Child wall: 1.785 s
Child high-water RSS : 47.7 MiB
Run
So, it seems like `gc:arc` uses about 70% the average CPU time, 70% the peak
memory, and has a worst case time of 3 vs 260 microseconds or 87X better.
Especially given all my mishaps, but ordinarily good advice would be for
someone else to try to reproduce those kinds of qualitative answers. I tried
lowering the max pause time from 100 all the way down to 1 but couldn't get the
old collector below about 245 microseconds. Maybe there are some other ways to
tune it. As perhaps evidenced by my error, I usually just use markAndSweep and
don't worry about this particular corner of performance as I don't usually
write code with real-time requirements.
