Le 18 juil. 2010 à 03:03, Ryan McGann a écrit : >> > 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. >
Thank you for that! It's seems very accurate! So, correct me if I'm wrong (I just want to be sure that I got it), you are saying that if in put my networking code into a thread, then I will lost one cpu cycle for the thread creation and scheduling, then several other cycles for nothing to wait until the packet is downloaded (an so on for each packet transmission). Would it mean that my app will be less responsive because switching between threads for nothing (is this a performance cost?), or just that my download will take more time ? Another aspect : would the memory required to run another thread have a significant impact on my app memory footprint ? (I guess it all depends on the number of threads?) Regards, Rafael_______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
