Sometimes I feel like a dinosaur. I went to school and cut my teeth in software development in an age where, to get acceptable results, you needed to understand what the computer was doing. That meant understanding size and space tradeoffs. It meant explicitly controlling the computer and its runtime so it did what you needed it to do, rather than what it wanted to do.
There were glorious hacks in the late 80s that were clearly innovative ideas designed to squeeze the most out of platforms. The virtual memory linker was one. In order to run more code than could physically fit on an x86 DOS machine, a linker was implemented that cut your app into pages that could be swapped in and out of memory and executed. To make that technique work better, we worked with a company called MicroQuill which built an analysis tool that, after studying your program’s execution (don’t forget the hours, days, nights and weeks of instrumentation), rearranged your functions into pages where they had the highest probability of being called by another function in the same page. Memory was small, disks were slow and we needed to squeeze every ounce of potential power out of the platform — for our customers.
The reason this all comes back to mind is because of an interesting discussion about garbage collection and memory management on an iPhone discussion group. In today’s web world, many commercial sites are based on script languages. Many of which are extremely powerful and fairly quick. The ability to run on such high-level languages is a testament to the computer hardware that we all have cheap access to. Many developers do amazing things with lightning speed on such platforms. If your resulting app runs slow, get more hardware, or order up some additional compute resources from the cloud. Problem solved.
An iPhone developer was lamenting the absence of the garbage collector in complex structures where the graph is difficult to follow and apparently clean up after. The discussion was in the context of autorelease pools being inappropriate for that task. Interestingly, the GC, while handy and making things much easier for developers, works on explicit actions. For an object to fall out of the the reference tree and into the garbage collector, you have to explicitly do something to remove that reference. This activity seems like exactly the moment you would want to perform memory management — to reduce the retain count (refcount for you COM dinosaurs) count on the object that you’re done with. Just a bit of extra code to explicitly do what you want the GC to do for you.
The iPhone lacks a garbage collector, but the Android has one. Advantage Google? Perhaps not. The way I tend to think about this is that Apple decided explicitly that they didn’t want GC running while a developer wanted their code to run. The consequence of this is to either hold collectable references longer if you have a GC or make the developer explicitly do the work. As a developer, I don’t want unused memory stuck waiting for a process that will “steal” CPU cycles from me for the purpose of discovering stuff that my code explicitly said that I’m done with. Why walk an allocation tree when you don’t have to?
On the other hand, if I was designing a platform to be easy to develop for, or one where additional compute resources were available simply by scaling horizontally, I’d make developing code the easiest and fastest process possible. The thing that is interesting to me is that it seems that it is easier for a “dinosaur” who is used to doing things themselves and has a relatively deep understanding of what’s going on at the lowest levels to adjust to a less-constrained development world.
While I’m not sure that this is the case for the people I’m discussing this with, people who see horizontal scaling and cloud compute power as a resource only limited by cash, perhaps ponied up by an investor, have a more difficult time adjusting to doing things themselves, and truly understanding the cost and implication of their decisions. It is a tough realization when you find that buying a second iPhone doesn’t make the app running on the first one any faster.