3 ms·
I think most people's concern with GC is not the allocation side of it? And in any case alloca blows them all out of the water. > if latency matters you end u
by couchand 3y ago
I think most people's concern with GC is not the allocation side of it? And in any case alloca blows them all out of the water.
> if latency matters you end up having to care about (de)allocation patterns at the app level.
Yes, and you want tools that allow you to precisely describe your needs, which might be more difficult if a lumbering brute is standing between you and your data.
- hgs3 3y agoMost GC concerns surround "stop the world" tracing collectors that "pause" the program unpredictably for an indeterminate time. These collectors are bad for real-time and soft real-time applications for obvious reasons. They would do better with a reference counting collector because its GC bookkeeping is smeared predictably across the run of the program. Most languages don't use reference counting because most applications are either one-shot console apps, GUI apps, or web apps - the latter two operate on "bursts" of input. If your app operates in "bursts" then a tracing GC is superior since you can delay collection until the app is waiting for more input. Real-time apps don't have a moment where they "wait" therefore they should prefer reference counting for its predictable performance. You have to use the right GC algorithm for the right job, but unfortunately programming language runtimes don't usually offer a choice.