[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