On 6 Dec 2012, at 05:33, Graham Cox graham@bigpond.com wrote:
On 05/12/2012, at 8:09 PM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote:
for( NSUInteger i = 0; i self.nbrWork; i++ )
{
GmdOperationBasis *m2 = [ [ GmdOperationBasis alloc ] init ];
[
On 06/12/2012, at 8:51 PM, Gerriet M. Denkmann gerr...@mdenkmann.de 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.
On Dec 4, 2012, at 23:02 , Gerriet M. Denkmann gerr...@mdenkmann.de 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
On 5 Dec 2012, at 15:07, Quincey Morris quinceymor...@rivergatesoftware.com
wrote:
On Dec 4, 2012, at 23:02 , Gerriet M. Denkmann gerr...@mdenkmann.de wrote:
And got almost the same overhead (tested three times with 99 operations);
clock time per operationexpected time
On Dec 5, 2012, at 01:09 , Gerriet M. Denkmann gerr...@mdenkmann.de 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 04:41, Kyle Sluder k...@ksluder.com 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
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
On Dec 5, 2012, at 2:05 AM, Mike Abdullah cocoa...@mikeabdullah.net wrote:
On 5 Dec 2012, at 04:41, Kyle Sluder k...@ksluder.com wrote:
NSOperationQueue uses KVO for dependency tracking and queue width
management. In 10.7, the implementation was apparently changed to thunk
all KVO ops
On 05/12/2012, at 8:09 PM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote:
for( NSUInteger i = 0; i self.nbrWork; i++ )
{
GmdOperationBasis *m2 = [ [ GmdOperationBasis alloc ] init ];
[ self.operationQueue addOperation: m2 ];
};
This is also
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
On Dec 4, 2012, at 10:15 AM, Gerriet M. Denkmann gerr...@mdenkmann.de 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
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 gerr...@mdenkmann.de wrote:
I have an
On 5 Dec 2012, at 01:55, Mike Abdullah cocoa...@mikeabdullah.net 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,
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 takes
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
On 4 Dec 2012, at 19:01, Gerriet M. Denkmann gerr...@mdenkmann.de wrote:
On 5 Dec 2012, at 01:55, Mike Abdullah cocoa...@mikeabdullah.net 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,
On 5 Dec 2012, at 02:58, Kyle Sluder k...@ksluder.com 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 [
On Tue, Dec 4, 2012, at 05:02 PM, Gerriet M. Denkmann wrote:
On 5 Dec 2012, at 02:58, Kyle Sluder k...@ksluder.com 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 -
On Dec 4, 2012, at 7:33 PM, Kyle Sluder 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 switching to threads while you append more and more
operations to the queue.
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 switching
On 5 Dec 2012, at 11:41, Kyle Sluder k...@ksluder.com wrote:
On Dec 4, 2012, at 8:00 PM, Jens Alfke j...@mooseyard.com wrote:
On Dec 4, 2012, at 7:33 PM, Kyle Sluder k...@ksluder.com wrote:
Yeah, it sounds like you're saturating the thread pool due to
non-CPU-bound operations.
21 matches
Mail list logo
