8 ms·
Why would I want to run a garbage collector and deal with it's performance penalties?
by 762236 10mo ago
Why would I want to run a garbage collector and deal with it's performance penalties?
- palata 10mo agoEasy: because in your specific use-case, it's worth trading some performance for the added safety.
- jerf 10mo agoBecause about 99% of the time the garbage collect is a negligible portion of your runtime at the benefit of a huge dollop of safety. People really need to stop acting like a garbage collector is some sort of cosmic horror that automatically takes you back to 1980s performance or something. The cases where they are unsuitable are a minority, and a rather small one at that. If you happen to live in that minority, great, but it'd be helpful if those of you in that minority would speak as if you are in the small minority and not propagate the crazy idea that garbage collection comes with massive "performance penalties" unconditionally. They come with conditions, and rather tight conditions nowadays.
- hypeatei 10mo agoI think these threads attract people that write code for performance-critical use cases which explains the "cosmic horror" over pretty benign things. I agree though: most programs aren't going to be brought to their knees over some GC sweeps every so often.
- KerrAvon 10mo agoOutside of hobbyist things, performance-critical code is the only responsible use case for a non-memory safe language like C in 2025, so of course it does. (Even that window is rapidly closing, though; languages like Rust and Swift can be better than C for perf-critical things because of the immutability guarantees.)
- lelanthran 10mo ago> Outside of hobbyist things, performance-critical code is the only responsible use case for a non-memory safe language like C in 2025, so of course it does. Maybe; I sometimes write non-hobbyist non-performance-critical code in C. I'm actually planning a new product for 2026 that might be done in C (the current iteration of that product line is in Go, the previous iteration was in Python). I've few qualms about writing the server in C.
- josephg 10mo ago> I've few qualms about writing the server in C. Bad Unicode support. Lack of cross platform system libraries. Needing to deal with CMake / autotools / whatever. Poor error handling. No built in string, list or map types. No generics. Nullability. No sum types. No option, tuples or multi returns. Generally worse IDE support than a lot of languages. No good 3rd party package ecosystem. The modern idiocy of header files. Memory bugs. Debugging memory corruption bugs. … I mean, yeah other than all those problems, C is a great little language.
- lelanthran 10mo ago> Bad Unicode support. Lack of cross platform system libraries. Needing to deal with CMake / autotools / whatever. Poor error handling. No built in string, list or map types. No generics. Nullability. No sum types. No option, tuples or multi returns. Generally worse IDE support than a lot of languages. No good 3rd party package ecosystem. The modern idiocy of header files. Memory bugs. Debugging memory corruption bugs. … You make some good, if oft-repeated, points; but for my product: 1. Bad Unicode support - I'm not sure what I will use this for; glyphs won't be handled by a server program and storage/search of UTF8/codepoints will be handled by the data store (PostgreSQL, if you must know). 2. CMake/autotools/etc - low list of 3rd party dependencies, so a plain Makefile works. 3. Worse IDE support than a lot of languages - not sure what you mean by this. C has LSP support, like every other language. I haven't noticed C support in editors to be worse than other languages. 4. No 3rd party package ecosystem - That's fine, I'm not pulling in many 3rd party packages, so those that are pulled in can be handled with the Makefile and manual updates. 5. The modern idiocy of header files - this confuses me; there is still no good alternative to header files to support exporting to a common ABI. Functions, written in C, will be callable from any other language because header files are automatically handled by swig for FFI.[1] 6. Memory bugs + debugging them - thankfully, using valgrind, then sanitisers in my build/test step makes this a very low priority for me. Not that bugs don't slip through, but single-exit error handling using goto's and cleanups make these kinds of bugs rare. Not impossible, but rare. Having the test steps include valgrind, then various sanitisers reduces the odds even more. For the rest, yeah, nice to have "No built in string, list or map types. No generics. Nullability. No sum types. No option, tuples or multi returns. ", but those are optional to getting a product out. If C had them I'd use them, but I'm not exactly helpless without them. The downside of writing a product in C, in 2025, isn't in your list above. ======================================== [1] One of my two main reasons for switching to C is because the product was so useful to paying clients that they'd like more functionality, which includes "use their language of choice to interact with the product.". Thus far I've hacked in solutions depending on which client wanted what, but there's limits to the hacked-in solutions. IOW, "easily extendable by clients using their language of choice" is a hard product requirement. If it wasn't a hard requirement they can continue using the existing product.
- Phil_Latio 10mo ago> Because about 99% of the time the garbage collect is a negligible portion of your runtime In a system programming language?
- pjmlp 10mo agoYes, plenty have been done already so since Lisp Machines, Smalltalk, Interlisp-D, Cedar, Oberon, Sing#, Modula-2+, Modula-3, D, Swift,.... It is a matter to have an open mindset. Eventually system languages with manual memory management will be done history in agentic driven OSes.
- KerrAvon 10mo agoSwift, by design, does not have GC.
- pebal 10mo agoRC is a GC method and the least efficient one.
- winrid 10mo agoIt's the most predictable and has much less overhead than a moving collector.
- pjmlp 10mo agoOnly when we forget about the impact of cycle collections, or domino effects stoping the world when there is a cascade of counters reaching zero. The optimisatios needed to improve such scenarions, are akin to a poor man's tracing GC implementation.
- winrid 10mo agoI didn't forget. That's predictable. It happens when the application code does something, or stops doing something, as opposed to the moving collector just doing it at random times.
- 762236 10mo agoFor new projects, I just use Rust: there is zero reason to deal with a garbage collector today. If I'm in C, it's because I care about predictable performance, and why I'm not using Java for that particular project.
- greenavocado 10mo agohttps://docs.rs/gc/latest/gc/ https://docs.rs/gc/latest/gc/
- 762236 10mo agoI don't understand. This is an optional part of Rust. I'm obviously not using a garbage collector in Rust.
- bigstrat2003 10mo agoNot really sure what relevance a third party library has when discussing the language characteristics.
- deleted 10mo ago[deleted]
- jesse__ 10mo ago> Because about 99% of the time the garbage collect is a negligible portion of your runtime lol .. reality disagrees with you. https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf#:~:text=We%20show%20that%20GenMS%2C%20an%20Appel%2Dstyle%20generational,sizes%2C%20ultimately%20running%2070%25%20slower%20on%20average. https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf#:~:te... On page 3 they broadly conclude that if you use FIVE TIMES as much memory as your program would if managed manually, you get a 9% performance hit. If you only use DOUBLE, you get as much as a 70% hit. Further on, there are comprehensive details on the tradeoffs between style of GC vs memory consumption vs performance. --- Moving a value from DRAM into a CPU register is an expensive operation, both in terms of latency, and power consumption. Much of the code out in the "real world" is now written in garbage collected languages. Our datacenters are extremely power hungry (as much as 2% of total power in the US is consumed by datacenters), and becoming more so every day. The conclusion here is that garbage collection is fucking expensive, in real-world terms, and we need to stop perpetuating the idea that it's not.
- atherton94027 10mo agoMethodology seems kind of dubious: > We introduce a novel experimental methodology that lets us quan- tify the performance of precise garbage collection versus explicit memory management. Our system allows us to treat unaltered Java programs as if they used explicit memory management by relying on oracles to insert calls to free. These oracles are generated from profile information gathered in earlier application runs.
- jesse__ 10mo agoWhat specifically seems dubious about that? I thought it was quite a clever idea.
- atherton94027 10mo agoIf you dig into the paper, on page 3 they find out that their null oracle approach (ie without actually freeing the memory) increases run times erratically by 12 to 33%. They then mention that their simulated approach should handle that case but it seems unlikely to me that their stats aren't affected. Also they disable multi-threading – again for repeatability – but that will obviously have a performance impact.
- mbac32768 10mo agoThe Java stop-the-world garbage collector circa the late 90s/early 2000s traumatized so many people on automated garbage collection.
- sesm 10mo agoIDK about Fil-C, but in Java garbage collector actually speeds up memory management compared to C++ if you measure the throughput. The cost of this is increased worst-case latency. A CLI tool (which most POSIX tools are) would pick throughput over latency any time.
- zozbot234 10mo agoYou also pay for the increased throughput with significant memory overhead, in addition to worst-case latency.
- KerrAvon 10mo agoThis. The memory overhead kills you in large systems/OS-level GC. Reducing the working set size really matters in a complex system to keep things performant, and GC vastly expands the working set. In the best cases, you’re losing a huge amount of performance vs. an equivalent non-GC system. In the worst, it affects interactive UI performance with multi-second stalls (a suitably modern GC shouldn’t do this, though).
- dataflow 10mo ago> in Java garbage collector actually speeds up memory management compared to C++ if you measure the throughput If I had a dollar for every time somebody repeated this without real-world benchmarks to back it up...
- jesse__ 10mo agoI wish I could upvote this 100 times
- CyberDildonics 10mo agoI see this claim all the time without evidence, but it's also apples and oranges. In C++ you can avoid heap allocations so they are rare and large. In java you end up with non stop small heap allocations which is exactly what you try to avoid when you want a program to be fast. Basically java gc is a solution to a problem that shouldn't exist.
- cryptonector 10mo agoBecause C is very unsafe, but there are still many billions of lines of C in use, so making C safer is a great idea.