3 ms·
I don't think this is quite the right attitude but I still agree with the basic concept. If you are building a high-end video game (my field), garbage collecti
by jblow 12y ago
I don't think this is quite the right attitude but I still agree with the basic concept.
If you are building a high-end video game (my field), garbage collection simply makes the user experience poorer than it would be otherwise. It is not some invisible implementation factor, but in fact affects the output in the form of stuttering frame times all over the place.
Good luck trying to do a VR game with a reasonable amount of stuff on screen with a GC running (you need to be between 75-90fps times 2 eyes. And every time you miss the frame deadline in VR, it is not just that the game feels worse, but it disorients people and gives them headaches and nausea.)
Every time I pick up an Android phone and try to use it, I want to throw it out a window, because it is all stuttery and janky. I presume at least part of this is because of GC.
I think this is another occurrence of people improperly weighing obvious benefits versus hidden costs. The obvious benefit of GC is you don't have to manage your memory so much, maybe. (I say maybe because when you start saying that GC performance is not good, the answer is always thinking about memory management in some way in order to reduce load on the GC. "It's a really great car as long as you don't drive it very much.") The obvious benefit is there, but there is also a hidden cost in terms of performance and solid-feeling-ness, and that cost is really pretty large actually. The theory has always been "pretty soon now GCs will get better and this will go away", but this has never happened. I went to college in 1989-94 and used to design GC'd languages as a hobby, so I have witnessed a couple of decades of this.
As a productive working programmer who writes a lot of code that does complicated things, I do not find the memory management to be a large part of what takes my time. If I were to pull a not-scientifically-derived number out of a hat, I would say it takes less than 2% of my time. To get a 2% improvement in productivity, but to pay for it so heavily ("well, there's a class of results that are simply impossible for me to achieve now because the GC might go off at any time"), is just a really bad tradeoff.
I am sympathetic to the idea that some paradigms of programming (functional, etc) are harder to do without GC. Exploring those ways of programming is a good reason to like GC, but given that functional programming is not really quite here yet for most classes of large and demanding problems, well, it's just a very different world from the one I need to build software in today.
- jheriko 12y agoactually GC's aren't that bad. considerate apps on android will not hitch from the GC unless the device is quite old my bigger problem is debugging these things. whenever i am forced into this environment i usually end up debugging someone elses memory problem and having a really hard time of solving it because of the sloppy practice GC encourages of not thinking about memory, so you end up with some weird distant or circular reference to an object preventing it from being deleted when you know better - that the problem is the coding style which allows that reference. new and delete force you to think a tiny bit, just enough to not shoot yourself in the foot like that. i'm always extra bitter because i have a track record of writing software where the only problematic leaks are from gc or ref counted stuff in opaque libraries... if i never had to touch this stuff there are 3 or 4 apps that i wrote which would have had zero leaks.