Re: Data downloading performance
Re: Data downloading performance
- Subject: Re: Data downloading performance
- From: Rafael Cerioli <email@hidden>
- Date: Sat, 17 Jul 2010 11:38:48 -0400
Le 17 juil. 2010 à 06:38, Mike Abdullah a écrit :
>
> On 17 Jul 2010, at 07:02, Kyle Sluder wrote:
>
>> On Fri, Jul 16, 2010 at 10:36 PM, Rafael Cerioli
>> <email@hidden> wrote:
>>> 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.
>>
>> Well, sort of. I believe what actually happens is that it uses a
>> private helper thread to perform the communication but notifies its
>> delegate on the main thread. But that's an implementation detail that
>> I might well have wrong. All that matters is that something gets
>> scheduled on the calling thread's runloop that is responsible for
>> notifying the delegate.
>
> That is correct. The connection is scheduled on the current thread, but the actual protocol implementations all happen on a single shared thread. Implementation detail though; doesn't matter to vast majority of uses!
Just out of curiosity, if there is communication between threads, even with runloops, there must be a lock at some point ? To schedule something in the main thread's runloop, you must lock the runloop don't you ?
>>
>>> 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.
>>
>> Guessing is not helpful. Start at the highest level of abstraction. If
>> you can demonstrate with actual data that it poses a problem, then
>> remove one layer of abstraction.
>
> Hear hear!
>>
>>> Isn't it better to use -[NSData initWithContentOfURL:] synchronous load
>>> method in background thread ?Or is there something wrong about that kind of
>>> use ?
>>
>> It uses NSURLDownload, which has had its own share of problems:
>> http://lists.apple.com/archives/Cocoa-dev/2007/Jun/msg00117.html
>
> Really? I'd be very surprised if this were the case. Why download the file to disk if it's wanted in memory anyway?
I don't think it uses NSURLDownload, on iOS :
(URL Loading system programming guide)
"iPhone OS Note: The NSURLDownload class is not available in iPhone OS, because downloading directly to the file system is discouraged. Use the NSURLConnection class instead. See “Using NSURLConnection” for more information."
and yet NSData initWithContentOfURL is available on iOS.
>>
>> In general, the answer to your Cocoa problems is not "spawn a thread."
I took a look at XMLPerformance sample code. Apple does a very good job there, it shows you how libXML2 can be use much more efficiently than NSXMLParser.
They run a NSURLConnection in a background thread and it works great ! Maybe they do that because as Ken Thomases pointed out, the parsing itself is a tough task and with libXML they have the opportunity to do that during the download, only with chunks of data.
But still, why would I bother running my NSURLConnection on the main thread, knowing that my parsing will have to be done in a background thread and I would have to deal with synchronization matter ? Why not just doing all the stuff in an NSOperation or a "detachedNewThreadSelector" ? (I mean, if you take apart the bugs reported, which apparently does not occur on iOS, not anymore in any case)
I'm looking for a technical explanation there, not just a "don't do that" because of general opinion, I don't like much "common beliefs" if they aren't justified by some technical proofs (again if you take apart the bug thing - assume this works with no bugs, is it just more or less efficient ?).
>>
>>> By the way, I never seen any bug about NSURLConnection running in background
>>> threads on iPhone OS.
>>
>> See above, but also here for the exact backtrace:
>> http://lists.apple.com/archives/cocoa-dev/2008/May/msg03073.html
>>
>> Again, this may have been fixed, the whole asynchronous thing might be
>> a red herring for a more pervasive bug that also affects asynchronous
>> use of the API, or (miracle of miracles) the bugs may have been fixed.
>> But the received wisdom is do not use NSURLConnection synchronously,
>> especially since it doesn't really give you any benefit to start with.
>>
>> --Kyle Sluder
>> _______________________________________________
>>
>> 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
>
_______________________________________________
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