Re: Quartz/memory benchmarks...
Re: Quartz/memory benchmarks...
- Subject: Re: Quartz/memory benchmarks...
- From: Kyle Hammond <email@hidden>
- Date: Thu, 27 Jun 2002 10:32:21 -0500
Hi,
I've found this thread to be fairly interesting, but am not seeing any
of the slowness that has been talked about.
I wrote a custom NSView subclass for a finance application to show
reports. One of the reports is seven columns of data; each column/row
position is a string with attributes. With the window expanded to show
just 27 rows (it can show a lot more on a big screen) that's 27 * 7 =
189 calls to NSString's -drawInRect:withAttributes: call. This view
scrolls as smooth as silk on my 400 Mhz G4 PowerBook.
I didn't do any special optimizations. The only couple of things that
may be of interest are that I preallocate the attribute dictionaries in
the NSView -initWithFrame: method. The data strings themselves are
calculated and cached in an NSMutableArray before drawing them. The
column widths are also pre-calculated so the drawing method just loops
over rows and columns and draws strings if they're contained in the
NSRect passed to -drawRect:
If you want to check it out, to make sure I'm not kidding, download the
application from <
http://cocoabudget.home.att.net/budget.dmg.gz> Once
you have the DMG, open the Sample data file with the Budget application
and use the Tools menu Reports command. The default report that comes
up is the one I'm talking about.
Armed with the above information, I humbly suggest that Quartz is not
the problem. What you're calculating in the -drawRect: method may be
the problem.
I'd try to use Sampler.app to get better information about what methods
are causing the slowdown. Get your app view ready to scroll, then
connect to the app with Sampler.app and start sampling. Scroll the view
a bunch of times (all the way from top to bottom maybe) and then stop
sampling. Find the scrolling method calls and search down from there to
see what's taking so long.
Best of luck,
Kyle
I am busy building a benchmarking simple demo app to show why
my app runs like a snail on heat.
My initial results show that string drawing is a killer - about 4mS
per call. That may seem fast to some people, but take a multi row
multi column table view and that translates easily into a 50 or more
calls for a not particular big screen). Thats 50*.004 = 0.2 second
just to draw the strings. (Line drawing is much fast as would be
expected).
Now hit the up or down arrow a number of times and we are into real slow
response.
This is using [NSString drawAt:]. I have experimented with directly
calling the NSLayoutManager and as yet I am 25% slower than NSString, so
I am missing some optimisations.
---------------------
Kyle Hammond
email@hidden
http://www.CodeBlazer.com/ - multimedia software solutions
http://www.isd.net/dsl03002/ - my personal home page
http://cocoabudget.home.att.net/ - Budget for MacOS X home page
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.