[OT] Why mobile web apps are slow

Paulo Pinto pjmlp at progtools.org
Thu Jul 11 01:46:44 PDT 2013


On Thursday, 11 July 2013 at 07:34:48 UTC, Jacob Carlborg wrote:
> On 2013-07-10 20:43, Paulo Pinto wrote:
>
>> What sometimes goes missed between the lines is that one of the
>> decisions to go ARC instead of GC, is because the Objective-C 
>> GC never
>> worked properly and ARC offers a better fit for the current 
>> state of
>> Objective-C world.
>>
>> First of all, GC was an opt-in and very few libraries 
>> supported it.
>
> Wasn't it possible to use the GC with all libraries but not the 
> other way around?

No, it depended how you compiled the code.

https://developer.apple.com/legacy/library/#documentation/Cocoa/Conceptual/GarbageCollection/Articles/gcEssentials.html#//apple_ref/doc/uid/TP40002452-SW1

Using -fobjc-gc-only meant your library could only work with GC 
enabled applications.

Or another quote from the documentation:

"Not all frameworks and technologies support garbage collection; 
for example, iCloud is not supported in applications that use 
garbage collection."


>
>> Then we have the typical issues with a conservative GC in a C 
>> based
>> language, which lead to tons of issues if one looks into 
>> developer forums.
>
> The GC only worked for the Objective-C part.

True, but you were forced to do manual hacks like calling 
objc_assign_global() for write barriers in global and static 
variables.

There is the compiler flag -Wassign-intercept to show where write 
barriers are being generated as a help method if everything is 
being generated properly.

The Core Foundation needs to be used in a slight different way 
when interacting with GC enabled objects.

With ARC all these problems do not exist, because the compiler 
does what the developers would be expected to do manually anyway.

This is way there was such a joy when ARC was announced, not 
because GC per se is bad.

--
Paulo


More information about the Digitalmars-d mailing list