Re: Data downloading performance
Re: Data downloading performance
- Subject: Re: Data downloading performance
- From: Ken Thomases <email@hidden>
- Date: Sat, 17 Jul 2010 04:51:54 -0500
On Jul 17, 2010, at 12:36 AM, Rafael Cerioli wrote:
> Le 16 juil. 2010 à 18:56, Kyle Sluder a écrit :
>
>> On Jul 16, 2010, at 3:46 PM, Rafael Cerioli <email@hidden> wrote:
>>
>>> - using a NSURLConnection seams nice, but as it calls its delegate (-connection:didReceiveData:) on the main thread, it has to take a lock on the main thread some times, hasn't it?
>>
>> No. Read up on NSRunLoop.
>
> I guess I had something wrong, NSURLConnection does not do anything in a background thread. It just operates in the main thread but "asynchronously" thanks to the run loop.
> Quote from NSURLConnection class reference :
> "At creation, a connection is scheduled on the current thread (the one where the creation takes place) in the default mode"
>
> That means, there is a lot of work done in the main thread. Even if the connection is not scheduled in the runloop "tracking" mode (for the UI), I guess the app would slow down at some point.
The asynchronous APIs invoked from the main thread do not _in and of themselves_ cause slowness or blocking of the main thread. Generally, there's nothing to do except when some event occurs (a connection is made, data arrives) and then the work done by Cocoa to respond to that event is relative simple and quick.
However, it then invokes your code (e.g. -connection:didReceiveData:), also on the main thread. If your code has to do time-consuming work in response, then it may make sense to offload that work to a background thread. This is complicated and difficult for a programmer new to threading to get correct, so it's not something to be undertaken lightly.
Following the design principles underlying NSOperation and NSOperationQueue helps a lot. In particular, operations should be self-contained. They should receive all the data they need at creation and only supply output data after they are finished. While they are running, they should not interact with outside state.
A serial (max. concurrent operations == 1) operation queue can be very useful if multiple operations have to operate on the same external state. They should do so one after the other, never simultaneously.
Cheers,
Ken
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden