Thanks for all the input. I solved it by using a straightforward C-array,
which I think also circumvents the scenario that Conrad describes about the
crash being caused by index 3 being set before index 2.
As it turns out, the time for the whole loop *decreased* by 5-10 fold by using
a dispatc
On Aug 12, 2013, at 11:23 AM, Koen van der Drift
wrote:
>
> On Aug 12, 2013, at 2:05 PM, Jens Alfke wrote:
>
>> NSMutableArray isn’t thread-safe. You’ll need to synchronize/serialize the
>> assignments somehow. You could do something like
>>
>> {
>> id value = [self doCalculation: i];
On Aug 12, 2013, at 2:05 PM, Jens Alfke wrote:
> NSMutableArray isn’t thread-safe. You’ll need to synchronize/serialize the
> assignments somehow. You could do something like
>
> {
> id value = [self doCalculation: i];
> @synchronized(myArray) {
> myArray[i] = value;
On Aug 12, 2013, at 10:36 AM, Koen van der Drift
wrote:
> dispatch_apply(count, queue, ^(size_t i)
> {
> myArray[i] = [self doCalculation: i];
> });
NSMutableArray isn’t thread-safe. You’ll need to synchronize/serialize the
assignments somehow. You could do something like
{
id
Hi,
I'm trying to use a queue for a calculation intensive for-loop to make my iOS
app more responsive. The original for-loop works without errors:
for (NSUInteger i = 0; i < count; i++)
{
myArray[i] = [self doCalculation: i];
}
When count gets too large, there is a delay when the resu
