Re: Performance
Re: Performance
- Subject: Re: Performance
- From: Alexander Spohr <email@hidden>
- Date: Wed, 18 Nov 2009 09:35:44 +0100
Am 16.11.2009 um 07:14 schrieb Chris Carson:
> The first class is the model that submits asynchronous bulk reads to the USB device. The callback for these reads copies the received data from the buffer asynchronous filled by the request and into an NSData object that is allocated and added to an NSArray. The buffer that the asynchronous request was using is recycled into a new asynchronous request. So the pool of buffers is allocated once and reused while the NSData objects are continuously allocated and deallocated (when released by the controller).
>
> The second class is the view that uses an NSTimer to call [self setNeedsDisplay:YES] 24 times per second. The drawRect: method requests data from the data source (the third, controller class) and draws it with OpenGL.
Why? Only redraw if new data is available.
> The third class is the controller class that serves as a data source for the view. When the view calls the giveMeData: method, the controller class calls the buffer: method in the model class, which removes and returns the oldest NSData object in its NSArray. The controller then does some computations on it and passes it off to the view in a new NSData object.
This sounds like you poll the model? Use a the controller as a delegate of the model to avoid polling. Make it event driven.
> The application runs pretty well, and running it through the Leaks instrument there are no leaks except for 16-bytes when the application is first starting caused by IOUSBLib. However, looking at it in the Activity Monitor, the real memory used starts off at 25 MB and steadily grows to 250+ MB while the virtual memory starts off at about the same and steadily grows to about the same or sometimes close to 500MB, over the course of several minutes. This especially happens if I don't move the mouse for a while, or don't have the application in focus. As soon as a move the mouse or bring the application into focus, it's as if an autorelease pool is drained and the memory drops back down to 30-40MB real and 30-40MB virtual. This is annoying since the application hangs for 5 seconds or so when this memory draining is occurring. Has anyone dealt with this before? Any ideas on what could be causing this and how to work around it?
This is exactly the case. The run loop does nothing if it has no input to handle.
Alloc your own autorelease pools at places that look like they would alloc some amount of autoreleased objects. Loops, the method you fire with your timer! and the filling of the array.
I do have a comment in my code (fired by a timer) that looks like this:
// NSView's getRectsBeingDrawn:count calls [NSMutableData dataWithLength]
// those build up if we don’t get them away faster than the runloop
(@List: Should I file a radar?)
> Another related question:
>
> The number of asynchronous requests that the driver submits at once and the maximum number of objects in the NSArray are set to some constant. Now in theory, the requests should be added and drained "simultaneously" (i.e. by separate threads), but if I make this constant larger, I notice a greater delay between when data entering the USB device and being plotted. It's as if the asynchronous requests are being filled and added to the NSArray all in a group, and then drained by the view all in a group... maybe? Is this something subtle from the way run loops work? Is the USB asynchronous bulk read run loop source on the same thread as the view class's drawRect method?
That could be, depending on your code. I have no advice here.
atze
_______________________________________________
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
| References: | |
| | >Performance (From: Chris Carson <email@hidden>) |