MacOSX Performance

Karsten Wolf karstenwo at web.de
Tue Jan 25 05:41:35 UTC 2005


Snippet 1 updated for 10 times:
VM3.8.1b2: 30604
Using rectangles for damageCollection: 9249 msec
Using regions for damageCollection: 5783 msec
Using a list of rectangles with maximum size of 128 at 128 for caching:  
4486 msec

compared to:
31,455 3.8.5b1   <- I expected this in the 25k range considering the  
MHz difference (17" >= 1GHz)
8629 rectangle
8498 region

Actually my second run was a bit faster. I guess rebooting &  
disconnecting my 2nd monitor are responsible for this.

> Times are similar, but I'd prefer rectangles versus regions to avoid  
> excessive malloc work, and don't forget regions have an upper  
> boundary, so
> technically you  need a check to see if you are exceeding that, more  
> overhead.

Intuitively I prefer rectangles too but I think it's ok to use regions  
for damage collection in this special case. A region gets added 1  
rectangle for each ioShowDisplay() call. I never profiled my region  
adds...

When I began investigating the cached CopyBits approach I initially  
made that array 1000 rectangles big, sacrificing 8kb RAM. I recently  
decreased it to 300 because that value was never reached. After all  
that hassle with deferred QDFlushPortBuffer I believe here could be  
gained most.

A quick search at apple
http://developer.apple.com/documentation/Carbon/Reference/ 
QuickDraw_Ref/qdref_main/function_group_19.html
revealed that Color QuickDraw regions are limited to 64kb. 8 bytes per  
Rect (and iirc regions are constructed from Rects) makes more than 8000  
damage adds (if there are no other administrative memory needs).

> if (((check = (ioMSecs() - pastTime)) > 7) || check < 0) {
Aren't you using your deferrence counter "c"? Like:
	if ( ((check = (ioMSecs() - pastTime)) > 7) || (check < 0) || (c >  
someLimit) ) {

> if (CFRunLoopIsWaiting(GetCFRunLoopFromEventLoop(GetMainEventLoop())))  
> {
I must confess this line is most interesting to me. Looks like stuff  
that solves a problem...


regards
karsten




More information about the Squeak-dev mailing list