iPhone vs Android

Walter Bright via Digitalmars-d digitalmars-d at puremagic.com
Tue Sep 13 14:43:09 PDT 2016


On 9/13/2016 10:44 AM, Jonathan M Davis via Digitalmars-d wrote:
> Folks have posted here before about taking that approach with games and the
> like that they've written. In a number cases, simply being careful about
> specific pieces of code and avoiding the GC in those cases was enough to get
> the required performance. In some cases, simply disabling the GC during a
> critical piece of code and re-enabling it afterwards fixes the performance
> problems trigged by the GC without even needing manual memory management or
> RC. In others, making sure that the critical thread (e.g. the rendering
> thread) was not GC-managed while letting the rest of the app us the GC
> takes care of the problem.
>
> We need reference counting to solve certain problems (e.g. cases where
> deterministic destruction of stuff on the heap is required), but other stuff
> (like array slices) work far better with a GC. So going either full-on RC or
> full-on GC is not going to be good move for most programs. I don't think
> that there's any question that we'll be best off by having both as solid
> options, and best practices can develop as to when to use one or the other.

Case in point, exceptions. Currently exceptions are fairly wedded to being GC 
allocated. Some people have opined that this is a major problem, and it is if 
the app is throwing a lot of exceptions. But exceptions should be exceptional.

There is still a place for GC, even in a high performance app. The 
all-or-nothing approach to using the GC is as wrong as any programming 
methodology is.



More information about the Digitalmars-d mailing list