In defence of Objective-C

Post by TheNewAndy » Tue, Oct 18, 2011, 12:28 PM UTC

dpark wrote: post #114

dextorious wrote: post #108

Earlier quoted context omitted.

> This will involve some work to break the correct-sized piece of memory off some larger block, and some bookkeeping for later restoring that memory to the block and possibly enlarging the block, merging with others, etc. This manual work incurs a penalty only for the developer, not for the performance. And you get to fine tune your memory allocations to your program's behavior. > in a modern generational GC, a mallo…

No, the work I described is not done by the typical developer. When's the last time you coded your own malloc ? Under the covers, though, malloc has to a lot of expensive bookkeeping of the sort I described that modern GC doesn't have to worry about. And GC can be more efficient in terms of memory usage as well. Modern GCs compact and so avoid most loss due to fragmentation. Where malloc will generally leave blocks p…

Just as a counter to your assertions - the code base I work on at work has its own memory allocation in it. It isn't the same as malloc, because all memory is allocated up front (and done by the caller, not the callee). There are no gaps in the memory (aside from those for aligning things nicely) and there is not really any way that you could make the memory usage any better in these regards (e.g. it is dense, and there is zero overhead after initialisation).

Garbage collected languages prevent this sort of thing from working, because they force overhead, and even though they might be able to do better than a lazy programmer, a person who cares about what they are doing will do ok.

Re: In defence of Objective-C

Re: In defence of Objective-C