On 7 Mar 2008, at 5:26 AM, Adam Maxwell wrote: > In article <[EMAIL PROTECTED]>, > Christiaan Hofman <[EMAIL PROTECTED]> wrote: > >> On 7 Mar 2008, at 1:18 AM, Adam Maxwell wrote: >> >>> In article >>> <[EMAIL PROTECTED]>, >>> "Christiaan Hofman" <[EMAIL PROTECTED]> wrote: >>> >>>> On Thu, Mar 6, 2008 at 1:52 PM, Christiaan Hofman >>>> <[EMAIL PROTECTED]> >>>> wrote: >>>> >>>>> A question for Adam: >>>>> I added most of your improvements to the FileView framework to the >>>>> BibDesk sources (such as improvements to icon classes and >>>>> operations/ >>>>> operation queues, as well as the new view widgets). I have >>>>> problems >>>>> with the operation queues though on my machine. I wonder if you >>>>> have >>>>> ideas on that as you wrote the code, it looks worthwhile to >>>>> include it. >>>>> >>>>> The problem is that with the test app I get a rather long beach >>>>> ball >>>>> at the start (about 20 sec), until the first set of visible icons >>>>> has >>>>> finished rendering. I don't have this problem with bibdesk where >>>>> typically only a few icons are visible at a time. It's probably >>>>> due to >>>>> the fact that the code is written for high performance machines >>>>> (multiple core?)? I'm using a single core 1.67 GHz PPC G4. >>> >>> I've actually tested it numerous times by disabling a processor on >>> my G5 >>> and MBP, and haven't had any beachballs (esp. not 20 seconds!). The >>> G5 >>> does have hanging issues with large batches of PDF files, due to >>> some >>> ATSServer locking bugs (spinning), but I can't reproduce it on the >>> MBP. >>> That's only evident after scrolling quickly, also. >>> >>>>> Things get better when I reduce the maxCurrentOperations to >>>>> _activeCPUs * 2 in FVConcreteOperationQueue. So perhaps this >>>>> number >>>>> should be dependent on some more system info (though I wouldn't >>>>> know >>>>> what, perhaps clock speed or arch)? >>> >>> The tuning right now is really crude, so it can likely be >>> improved. I >>> just didn't really know where to start (and based on Chris Kane's >>> cocoa-dev message I didn't bother). >>> >> >> I was wondering if something like kern.maxprocperuid / 100 would be a >> good measure. > > No idea on that; I'm not sure how (or if) Apple tunes that. Some of > the > default kernel tuning sucks (tiny number of open files, for instance). > >> >>>>> Perhaps it also has to do with the >>>>> fact that the old style FVIconQueue updated in batches of 5, while >>>>> the >>>>> operationQueues seem to work with single operations? >>> >>> The renders are each a single operation, and they all get dumped >>> into >>> the queue. The queue then grinds away as the kernel has resources. >>> >>> When each render op is done, it puts an update operation in the main >>> thread queue. You might have noticed that the main thread queue >>> subclass is completely different, since it's attached to the main >>> thread's runloop as a CFRunLoopObserver. I've seen those batched in >>> groups of 1-10, typically, so it should be more efficient than the >>> FVIconQueue as far as batching the view updates. >>> >> >> I was actually wondering why these OSSpinLocks are there, because it >> only works on the main thread AFAICS. > > The operations can be added to the queue ivar from an arbitrary > thread, > so the locks are required. They're only executed on the main thread > whenever it wakes up. I used spin locks since contention should be > low, > and that's what CF uses internally in CFRunLoop and other groovy > objects. > >> I also changed the batching of >> results a bit, which avoids some lock/unlock steps there (basically >> use makeObjectsPerformSelector on a temporary array instead of >> separately sending the operations a start message). Did not make much >> difference though. Probably it is also not the bottleneck, as the >> iconUpdated: messages don't seem to come very fast. > > Right, batching there should be unnecessary now; it was a hack > previously to keep from flooding the main CFRunLoop with a bunch of > updates.
You mean keeping the _activeOperations around? Indeed, - [FVIconUpdateOperation start] returns immediately, so it seems all it does is add some locks. However, that's an implementation detail, the queue doesn't know about that. For all it cares, it could spawn another thread. > The iconUpdated: call is also significantly more efficient due > to the index mapping, which avoids hashing URLs and collecting them > (slow). > Maybe that was the reason why iconQueue stopped working for me? After copying some partial changes from your version (I think it was changes to the icon classes and also the index mapping), the iconQueue kept firing with the old icons after the URLs had changed, so the view was never updated. Never really understood why. This was the reason I copied also the operation queue stuff. > The best optimizations were probably drawing the highlight and > placeholders as CGLayers, though, and that was also the easiest :). > Selection speed improved noticeably. > >>> It might be >>> interesting to substitute an NSOperationQueue and see if it has the >>> same >>> problem. I did that for initial testing, and it worked pretty well. >>> I'm not sure that there's a net performance gain by using operations >>> vs. >>> the FVIconQueue, but it's great when you have a single movie/image/ >>> pdf >>> that takes a really long time to render. >> >> >> I'm not sure where things should change for NSOperationQueue (I >> haven't looked into NSOperation(Queue) yet). > > NSOperationQueue looks like a replacement for OFMessageQueue in some > respects. FVOperationQueue is basically a reimplementation of Omni's > queueSelectorOnce:, since I thought it would be a fun challenge to > implement an NSOperation-like API that was 10.4 compatible. It looks nice. I hope I can figure out where the bottle neck is for me. Christiaan ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bibdesk-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
