Re: UITable Views and display lags / NSOperation vs NSURLConnection
Hmm, now I am confused because I just checked the docs for NSOperationQueue and it says: maxConcurrentOperationCount Returns the maximum number of concurrent operations that the receiver can execute. - (NSInteger)maxConcurrentOperationCount Return Value The maximum number of concurrent operations set explicitly on the receiver using the setMaxConcurrentOperationCount: method. If no value has been explicitly set, this method returns NSOperationQueueDefaultMaxConcurrentOperationCount by default. According to the above, if no value is explicitly set, the getter returns NSOperationQueueDefaultMaxConcurrentOperationCount, which would lead me to believe that that is the default. Yet, according to your experience, the default seems to be 1. So, which one is it? Does anyone in the list know for sure? W. On Mar 21, 2010, at 7:51 PM, Jack Carbaugh wrote: > W > > You were correct, I had not altered the queue to something other than the > default. After reviewing the docs, i found this ... > >> If you specify the value NSOperationQueueDefaultMaxConcurrentOperationCount >> (which is recommended), the maximum number of operations can change >> dynamically based on system conditions. > > > ... which, really, i think should be the default, rather than 1. Since i was > using an NSOperation in another area, i adjusted the queue to the > NSOperationQueueDefaultMaxConcurrentOperationCount value and noticed > significant improvement. > > Again, my thanks ... and yes, it is great to have alternatives. > > jack > > On Mar 21, 2010, at 2:42 PM, WT wrote: > >> And thank you for the NSURLConnection suggestion. It's always good to have >> alternatives. :) >> >> W. >> >> On Mar 21, 2010, at 7:25 PM, Jack Carbaugh wrote: >> >>> hmmm to be honest, I am not sure ... there is a possibility that i did NOT >>> adjust the max # of concurrent operations. >>> >>> I will look into this and THANK YOU for the insight. >>> >>> >>> On Mar 21, 2010, at 2:22 PM, WT wrote: >>> It was serial? Did you, by any chance, set the maximum number of running operations to 1? I don't recall for sure now, but that may be the default, actually. As far as I know, independent NSOperations in the same queue are executed in parallel, subjected to resource constraints and the maximum number of running operations. I'm not disputing your results, by the way. As you said, using NSURLConnection might be the best approach in some cases, and perhaps the OP's situation as well. I only suggested NSOperation because that's what I've successfully used a few times, with minimal effort. I'm about to start a project where I have to do precisely what the OP needs to do (fetch and display many images off the web), so I'll try both ways, time permitting. W. On Mar 21, 2010, at 7:06 PM, Jack Carbaugh wrote: > NSURLConnection does this as well. The main issue i had with using an > NSOperation/OperationQueue was that is was "serial" ... using the > NSURLConnection allowed me to handle MULTIPLE asynchronous downloads > which, when used with properties allowed near instantaneous UI updates. > > With the NSOperation avenue, it took longer, UI updates were not as fast > as the queue would handle only one operation at a time, in series. > > For me, the NSURLConnection route was just better for my specific needs > and, i think may be as well for the OP. > > jack > > On Mar 21, 2010, at 1:53 PM, WT wrote: > >> On Mar 21, 2010, at 6:25 PM, Jack Carbaugh wrote: >> >>> You don't need to overcomplicate downloading the images with an >>> NSOperation. >>> >>> In my experience, downloading asynchronously with an NSURLConnection >>> and the delegate methods works far better. >>> >>> Jack >> >> I don't think using NSOperation is overcomplicating things. It's >> entirely trivial to use it and, as far as I know, NSOperationQueue takes >> care of scheduling the threads to make the best use of the resources >> available. >> >> W.= ___ 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
Re: UITable Views and display lags / NSOperation vs NSURLConnection
W You were correct, I had not altered the queue to something other than the default. After reviewing the docs, i found this ... If you specify the value NSOperationQueueDefaultMaxConcurrentOperationCount (which is recommended), the maximum number of operations can change dynamically based on system conditions. ... which, really, i think should be the default, rather than 1. Since i was using an NSOperation in another area, i adjusted the queue to the NSOperationQueueDefaultMaxConcurrentOperationCount value and noticed significant improvement. Again, my thanks ... and yes, it is great to have alternatives. jack On Mar 21, 2010, at 2:42 PM, WT wrote: And thank you for the NSURLConnection suggestion. It's always good to have alternatives. :) W. On Mar 21, 2010, at 7:25 PM, Jack Carbaugh wrote: hmmm to be honest, I am not sure ... there is a possibility that i did NOT adjust the max # of concurrent operations. I will look into this and THANK YOU for the insight. On Mar 21, 2010, at 2:22 PM, WT wrote: It was serial? Did you, by any chance, set the maximum number of running operations to 1? I don't recall for sure now, but that may be the default, actually. As far as I know, independent NSOperations in the same queue are executed in parallel, subjected to resource constraints and the maximum number of running operations. I'm not disputing your results, by the way. As you said, using NSURLConnection might be the best approach in some cases, and perhaps the OP's situation as well. I only suggested NSOperation because that's what I've successfully used a few times, with minimal effort. I'm about to start a project where I have to do precisely what the OP needs to do (fetch and display many images off the web), so I'll try both ways, time permitting. W. On Mar 21, 2010, at 7:06 PM, Jack Carbaugh wrote: NSURLConnection does this as well. The main issue i had with using an NSOperation/OperationQueue was that is was "serial" ... using the NSURLConnection allowed me to handle MULTIPLE asynchronous downloads which, when used with properties allowed near instantaneous UI updates. With the NSOperation avenue, it took longer, UI updates were not as fast as the queue would handle only one operation at a time, in series. For me, the NSURLConnection route was just better for my specific needs and, i think may be as well for the OP. jack On Mar 21, 2010, at 1:53 PM, WT wrote: On Mar 21, 2010, at 6:25 PM, Jack Carbaugh wrote: You don't need to overcomplicate downloading the images with an NSOperation. In my experience, downloading asynchronously with an NSURLConnection and the delegate methods works far better. Jack I don't think using NSOperation is overcomplicating things. It's entirely trivial to use it and, as far as I know, NSOperationQueue takes care of scheduling the threads to make the best use of the resources available. W.= ___ 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
Re: UITable Views and display lags / NSOperation vs NSURLConnection
And thank you for the NSURLConnection suggestion. It's always good to have alternatives. :) W. On Mar 21, 2010, at 7:25 PM, Jack Carbaugh wrote: > hmmm to be honest, I am not sure ... there is a possibility that i did NOT > adjust the max # of concurrent operations. > > I will look into this and THANK YOU for the insight. > > > On Mar 21, 2010, at 2:22 PM, WT wrote: > >> It was serial? Did you, by any chance, set the maximum number of running >> operations to 1? I don't recall for sure now, but that may be the default, >> actually. As far as I know, independent NSOperations in the same queue are >> executed in parallel, subjected to resource constraints and the maximum >> number of running operations. >> >> I'm not disputing your results, by the way. As you said, using >> NSURLConnection might be the best approach in some cases, and perhaps the >> OP's situation as well. I only suggested NSOperation because that's what >> I've successfully used a few times, with minimal effort. >> >> I'm about to start a project where I have to do precisely what the OP needs >> to do (fetch and display many images off the web), so I'll try both ways, >> time permitting. >> >> W. >> >> On Mar 21, 2010, at 7:06 PM, Jack Carbaugh wrote: >> >>> NSURLConnection does this as well. The main issue i had with using an >>> NSOperation/OperationQueue was that is was "serial" ... using the >>> NSURLConnection allowed me to handle MULTIPLE asynchronous downloads which, >>> when used with properties allowed near instantaneous UI updates. >>> >>> With the NSOperation avenue, it took longer, UI updates were not as fast as >>> the queue would handle only one operation at a time, in series. >>> >>> For me, the NSURLConnection route was just better for my specific needs >>> and, i think may be as well for the OP. >>> >>> jack >>> >>> On Mar 21, 2010, at 1:53 PM, WT wrote: >>> On Mar 21, 2010, at 6:25 PM, Jack Carbaugh wrote: > You don't need to overcomplicate downloading the images with an > NSOperation. > > In my experience, downloading asynchronously with an NSURLConnection and > the delegate methods works far better. > > Jack I don't think using NSOperation is overcomplicating things. It's entirely trivial to use it and, as far as I know, NSOperationQueue takes care of scheduling the threads to make the best use of the resources available. W.= >>> > ___ 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
Re: UITable Views and display lags / NSOperation vs NSURLConnection
hmmm to be honest, I am not sure ... there is a possibility that i did NOT adjust the max # of concurrent operations. I will look into this and THANK YOU for the insight. On Mar 21, 2010, at 2:22 PM, WT wrote: It was serial? Did you, by any chance, set the maximum number of running operations to 1? I don't recall for sure now, but that may be the default, actually. As far as I know, independent NSOperations in the same queue are executed in parallel, subjected to resource constraints and the maximum number of running operations. I'm not disputing your results, by the way. As you said, using NSURLConnection might be the best approach in some cases, and perhaps the OP's situation as well. I only suggested NSOperation because that's what I've successfully used a few times, with minimal effort. I'm about to start a project where I have to do precisely what the OP needs to do (fetch and display many images off the web), so I'll try both ways, time permitting. W. On Mar 21, 2010, at 7:06 PM, Jack Carbaugh wrote: NSURLConnection does this as well. The main issue i had with using an NSOperation/OperationQueue was that is was "serial" ... using the NSURLConnection allowed me to handle MULTIPLE asynchronous downloads which, when used with properties allowed near instantaneous UI updates. With the NSOperation avenue, it took longer, UI updates were not as fast as the queue would handle only one operation at a time, in series. For me, the NSURLConnection route was just better for my specific needs and, i think may be as well for the OP. jack On Mar 21, 2010, at 1:53 PM, WT wrote: On Mar 21, 2010, at 6:25 PM, Jack Carbaugh wrote: You don't need to overcomplicate downloading the images with an NSOperation. In my experience, downloading asynchronously with an NSURLConnection and the delegate methods works far better. Jack I don't think using NSOperation is overcomplicating things. It's entirely trivial to use it and, as far as I know, NSOperationQueue takes care of scheduling the threads to make the best use of the resources available. W.= ___ 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
Re: UITable Views and display lags / NSOperation vs NSURLConnection
It was serial? Did you, by any chance, set the maximum number of running operations to 1? I don't recall for sure now, but that may be the default, actually. As far as I know, independent NSOperations in the same queue are executed in parallel, subjected to resource constraints and the maximum number of running operations. I'm not disputing your results, by the way. As you said, using NSURLConnection might be the best approach in some cases, and perhaps the OP's situation as well. I only suggested NSOperation because that's what I've successfully used a few times, with minimal effort. I'm about to start a project where I have to do precisely what the OP needs to do (fetch and display many images off the web), so I'll try both ways, time permitting. W. On Mar 21, 2010, at 7:06 PM, Jack Carbaugh wrote: > NSURLConnection does this as well. The main issue i had with using an > NSOperation/OperationQueue was that is was "serial" ... using the > NSURLConnection allowed me to handle MULTIPLE asynchronous downloads which, > when used with properties allowed near instantaneous UI updates. > > With the NSOperation avenue, it took longer, UI updates were not as fast as > the queue would handle only one operation at a time, in series. > > For me, the NSURLConnection route was just better for my specific needs and, > i think may be as well for the OP. > > jack > > On Mar 21, 2010, at 1:53 PM, WT wrote: > >> On Mar 21, 2010, at 6:25 PM, Jack Carbaugh wrote: >> >>> You don't need to overcomplicate downloading the images with an NSOperation. >>> >>> In my experience, downloading asynchronously with an NSURLConnection and >>> the delegate methods works far better. >>> >>> Jack >> >> I don't think using NSOperation is overcomplicating things. It's entirely >> trivial to use it and, as far as I know, NSOperationQueue takes care of >> scheduling the threads to make the best use of the resources available. >> >> W.= > ___ 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
Re: UITable Views and display lags / NSOperation vs NSURLConnection
NSURLConnection was indeed more appropriate for what I needed, and what I ended up using. On 21 Mar 2010, at 18:06, Jack Carbaugh wrote: > NSURLConnection does this as well. The main issue i had with using an > NSOperation/OperationQueue was that is was "serial" ... using the > NSURLConnection allowed me to handle MULTIPLE asynchronous downloads which, > when used with properties allowed near instantaneous UI updates. > > With the NSOperation avenue, it took longer, UI updates were not as fast as > the queue would handle only one operation at a time, in series. > > For me, the NSURLConnection route was just better for my specific needs and, > i think may be as well for the OP. > > jack > > On Mar 21, 2010, at 1:53 PM, WT wrote: > >> On Mar 21, 2010, at 6:25 PM, Jack Carbaugh wrote: >> >>> You don't need to overcomplicate downloading the images with an NSOperation. >>> >>> In my experience, downloading asynchronously with an NSURLConnection and >>> the delegate methods works far better. >>> >>> Jack >> >> I don't think using NSOperation is overcomplicating things. It's entirely >> trivial to use it and, as far as I know, NSOperationQueue takes care of >> scheduling the threads to make the best use of the resources available. >> >> W.= > > ___ > > 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/frak.off%40gmail.com > > This email sent to frak@gmail.com ___ 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
Re: UITable Views and display lags / NSOperation vs NSURLConnection
NSURLConnection does this as well. The main issue i had with using an NSOperation/OperationQueue was that is was "serial" ... using the NSURLConnection allowed me to handle MULTIPLE asynchronous downloads which, when used with properties allowed near instantaneous UI updates. With the NSOperation avenue, it took longer, UI updates were not as fast as the queue would handle only one operation at a time, in series. For me, the NSURLConnection route was just better for my specific needs and, i think may be as well for the OP. jack On Mar 21, 2010, at 1:53 PM, WT wrote: On Mar 21, 2010, at 6:25 PM, Jack Carbaugh wrote: You don't need to overcomplicate downloading the images with an NSOperation. In my experience, downloading asynchronously with an NSURLConnection and the delegate methods works far better. Jack I don't think using NSOperation is overcomplicating things. It's entirely trivial to use it and, as far as I know, NSOperationQueue takes care of scheduling the threads to make the best use of the resources available. W.= ___ 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
