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). > > 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. > > Any ideas how performance could be improved? > > > > Christiaan > > > > > Let me add some more observations. the main slowdown occurs when starting > up, so for the first full view of icons. Can you get a sample of this? Or run a time profile with Shark to profile the launch? What file types are you looking at? I'd really like to see where the bottleneck is. > If I then scroll for other icons ( > e.g. by hitting End) performance is pretty good. So could it be that some > initial creation/setup is a performance bottle neck? The slowdown only > occurs when there are many icons to display initially though, so it's not > just that the setup of the queue is slow. Queue setup should be trivial, especially using the raw mach port, so I think you're correct that something else is going on. 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. ------------------------------------------------------------------------- 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
