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. >>> 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. 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. >>> 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. > I'll try later. I'm looking at PDFs mostly, also some .scpt, images and text files. >> 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. Yea, I tried showing one icon first, and then showing a lot of icons, and this also gives the same slowdown. > 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). 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
