Re: Data downloading performance
Re: Data downloading performance
- Subject: Re: Data downloading performance
- From: Ryan McGann <email@hidden>
- Date: Sun, 18 Jul 2010 00:03:51 -0700
(Sorry, re-sending with the appropriate subject. Stupid copy & paste failed, my bad).
>> On Jul 16, 2010, at 3:46 PM, Rafael Cerioli <email@hidden> wrote:
>>
>>> Hi everybody,
>>>
>>> What would be the most efficient way to download data without blocking the UI (I'm targeting old iPhone/iPod devices) ?
>>>
>>> - 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.
Unfortunately, I can't find the sources at the moment as it was a while ago, but there was an interesting discussion about this topic on the macnetworkprog mailing list. Apple found in the early days of iPhone programming that threads are (in general), a bad idea for networking, and it was made worse by the fact that the iPhone has only 1 CPU. Apple's resident kernel networking engineers (the guys that would know about networking latency the most), as well as the venerable Quinn "the Eskimo" from Apple DTS, basically boiled it down to this:
Rule #1. Networking code is dominated by network latency, not CPU cycles.
Rule #2. Don't use threads for networking without thoroughly profiling your application.
Downloading a file, even if it can be done in a single TCP packet (after the RTT of the handshake) can take 20-30 milliseconds easily, and that's if the server responds instantaneously and no DNS lookup is involved. Your application only gets 10 milliseconds of CPU time anyway so it'll sleep several times before the file is received, and that's if a bunch of other things are true first.
Your application, if well behaved will never notice network latency. On the iOS devices, setting up a thread (creating the thread context, scheduling it in the kernel and context switching to the new thread) can take a full thread quantum. GCD helps but only so much.
Now, when SSL gets involved things are murkier. The certificate exchange can take 100's of milliseconds and is moderately CPU intensive (compared to the network data transfer which is relatively insignificant). It still all happens in the background (when using NSStream) and your application should get ample CPU time, but if you have several connections at once you could find your app getting slowed down.
If, and only if, you find your application is being blocked by threading (usually the result of SSL negotiation) then you should think about threading your networking. Otherwise, trust the threading model of the higher level networking APIs.
_______________________________________________
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