4 ms·
It's not a limitation, just a tuning knob that can be used to trade off GC cycles against memory usage. If you're in a low-memory environment, tune the knob to
by eloff 11y ago
It's not a limitation, just a tuning knob that can be used to trade off GC cycles against memory usage. If you're in a low-memory environment, tune the knob to use more CPU.
- cwyers 11y agoWhat if you're in a low-everything environment?
- Taek 11y agoAt some point you can no longer afford the luxury of a garbage collector. As the tech gets better, that point gets lower and lower, but there are still limitations.
- NateDad 11y agoPhones have two gigs of RAM and four cores these days. Low what? If you're talking software on an internet connected fridge, then, maybe, but that's a pretty niche area even in today's mostly theoretical and overpriced IOT world.
- millstone 11y agoThen don't use Go. Go was pitched as a systems language, but has found its niche as a server language. It's to be expected that the maintainers will make decisions that tune it for servers.
- wereHamster 11y agoDon't use a language which has GC. Allocate all objects statically.. no memory management needed at runtime.
- mehrdada 11y agoMy comment was targeting that particular statement and was not meant to be interpreted as a deficiency in this particular GC design, though if I were to comment about that, I have to say I remain a bit skeptical about how far you can effectively scale it down via this single knob technique; scaling up, I'm more certain about.
- eloff 11y agoFair enough. It might not scale down that well, especially since on low-memory systems you often worry about CPU usage and power usage as well. But Go uses a lot less memory to begin with, so the default GOGC value of 100% (half of application memory used, half free) will still be less than a similar Java program, even ignoring that Java also needs a heap larger than the allocated size to get good performance.