On 06/12/2012, at 8:51 PM, Gerriet M. Denkmann wrote:
> I am using Arc. And I used Instruments Leaks, which did not show any.
> Are you sure that this leaks under Arc?
>
Oh, sorry, forget it. I'm still not used to seeing code like this and it not
screaming "LEAK" at me. Maybe one of thes
On 6 Dec 2012, at 05:33, Graham Cox wrote:
>
> On 05/12/2012, at 8:09 PM, Gerriet M. Denkmann wrote:
>
>> for( NSUInteger i = 0; i < self.nbrWork; i++ )
>> {
>> GmdOperationBasis *m2 = [ [ GmdOperationBasis alloc ] init ];
>> [ self.operationQueue addOperation
On 05/12/2012, at 8:09 PM, Gerriet M. Denkmann wrote:
> for( NSUInteger i = 0; i < self.nbrWork; i++ )
> {
> GmdOperationBasis *m2 = [ [ GmdOperationBasis alloc ] init ];
> [ self.operationQueue addOperation: m2 ];
> };
This is also leaking, could that
On Dec 5, 2012, at 2:05 AM, Mike Abdullah wrote:
>
> On 5 Dec 2012, at 04:41, Kyle Sluder wrote:
>
>> NSOperationQueue uses KVO for dependency tracking and queue width
>> management. In 10.7, the implementation was apparently changed to thunk
>> all KVO ops onto the main thread; I'm guessing t
On Tue, Dec 4, 2012, at 08:00 PM, Jens Alfke wrote:
> Apologies, but I have trouble believing that. Isn’t NSOperationQueue just
> a thin veneer around GCD?
By the way, it's worth pointing out that NSOperationQueue is NOT a thin
veneer around GCD.
Blocks submitted to an NSOperationQueue are dispat
On 5 Dec 2012, at 04:41, Kyle Sluder wrote:
> NSOperationQueue uses KVO for dependency tracking and queue width
> management. In 10.7, the implementation was apparently changed to thunk
> all KVO ops onto the main thread; I'm guessing this fixed a bug by
> serializing all state changes. It also
On Dec 5, 2012, at 01:09 , "Gerriet M. Denkmann" wrote:
> When I press a button "Start" this gets done:
>
> self.start = [ NSDate date ];
> for( NSUInteger i = 0; i < self.nbrWork; i++ )
> {
> GmdOperationBasis *m2 = [ [ GmdOperationBasis alloc ] init ];
>
On 5 Dec 2012, at 15:07, Quincey Morris
wrote:
> On Dec 4, 2012, at 23:02 , "Gerriet M. Denkmann" wrote:
>
>> And got almost the same overhead (tested three times with 99 operations);
>> clock time per operationexpected time overhead factor
>> // 8 ops 29.9, 30.1, 29.7
On Dec 4, 2012, at 23:02 , "Gerriet M. Denkmann" wrote:
> And got almost the same overhead (tested three times with 99 operations);
> clock time per operationexpected time overhead factor
> //8 ops 29.9, 30.1, 29.712.52.4
> //7 ops 2
On 5 Dec 2012, at 11:41, Kyle Sluder wrote:
>
> On Dec 4, 2012, at 8:00 PM, Jens Alfke wrote:
>
>>
>> On Dec 4, 2012, at 7:33 PM, Kyle Sluder wrote:
>>
>>> Yeah, it sounds like you're saturating the thread pool due to
>>> non-CPU-bound operations. NSOpQ is going to spend its entire tim
On Dec 4, 2012, at 8:00 PM, Jens Alfke <[1]j...@mooseyard.com> wrote:
On Dec 4, 2012, at 7:33 PM, Kyle Sluder <[2]k...@ksluder.com> wrote:
Yeah, it sounds like you're saturating the thread pool due to
non-CPU-bound operations. NSOpQ is going to spend its entire time
spawning and switchin
On Dec 4, 2012, at 7:33 PM, Kyle Sluder wrote:
> Yeah, it sounds like you're saturating the thread pool due to
> non-CPU-bound operations. NSOpQ is going to spend its entire time
> spawning and switching to threads while you append more and more
> operations to the queue.
Apologies, but I have
On Tue, Dec 4, 2012, at 05:02 PM, Gerriet M. Denkmann wrote:
>
> On 5 Dec 2012, at 02:58, Kyle Sluder wrote:
>
> > On Tue, Dec 4, 2012, at 10:15 AM, Gerriet M. Denkmann wrote:
> >> I have an app which uses NSOperations inside an NSOperationQueue. These
> >> operations do not do any I/O - just Cp
On 5 Dec 2012, at 02:58, Kyle Sluder wrote:
> On Tue, Dec 4, 2012, at 10:15 AM, Gerriet M. Denkmann wrote:
>> I have an app which uses NSOperations inside an NSOperationQueue. These
>> operations do not do any I/O - just Cpu. No swapping is taking place.
>>
>> When I set [ self.operationQueue s
On 4 Dec 2012, at 19:01, "Gerriet M. Denkmann" wrote:
>
> On 5 Dec 2012, at 01:55, Mike Abdullah wrote:
>
>> If your operations are purely CPU-bound, the whole point of GCD is to manage
>> this for you. With the default number of concurrent operations,
>> NSOperationQueue does exactly that.
On Wed, 5 Dec 2012 01:15:11 +0700, Gerriet M. Denkmann said:
>I have an app which uses NSOperations inside an NSOperationQueue. These
>operations do not do any I/O - just Cpu. No swapping is taking place.
Do your operations use a lot of memory? Even though you're not swapping, maybe
you're blow
On Tue, Dec 4, 2012, at 10:15 AM, Gerriet M. Denkmann wrote:
> I have an app which uses NSOperations inside an NSOperationQueue. These
> operations do not do any I/O - just Cpu. No swapping is taking place.
>
> When I set [ self.operationQueue setMaxConcurrentOperationCount: 1 ] each
> operation t
On 5 Dec 2012, at 01:55, Mike Abdullah wrote:
> If your operations are purely CPU-bound, the whole point of GCD is to manage
> this for you. With the default number of concurrent operations,
> NSOperationQueue does exactly that. Have you tried with that setting?
I have, and it makes my app un
If your operations are purely CPU-bound, the whole point of GCD is to manage
this for you. With the default number of concurrent operations,
NSOperationQueue does exactly that. Have you tried with that setting?
On 4 Dec 2012, at 18:15, "Gerriet M. Denkmann" wrote:
> I have an app which uses NS
On Dec 4, 2012, at 10:15 AM, Gerriet M. Denkmann wrote:
> Is this to be expected? Or does my app has some hidden flaws? If so, where
> should I start looking?
Instruments. This is exactly what CPU profiling is for. If you can’t get
Instruments to work for you, that’s a separate issue, and you
I have an app which uses NSOperations inside an NSOperationQueue. These
operations do not do any I/O - just Cpu. No swapping is taking place.
When I set [ self.operationQueue setMaxConcurrentOperationCount: 1 ] each
operation takes on average 200 msec., measured by NSDate.
With 2 concurrent ope
21 matches
Mail list logo
