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. The iconUpdated: call is also significantly more efficient due to the index mapping, which avoids hashing URLs and collecting them (slow). 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. ------------------------------------------------------------------------- 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
