On Jan 20, 2008, at 9:52 AM, Christiaan Hofman wrote: > > On 20 Jan 2008, at 5:56 PM, Adam R. Maxwell wrote: > >> >> On Jan 20, 2008, at 8:35 AM, Christiaan Hofman wrote: >> >>> Would it be possible to initialize the SKIndexRef on the thread >>> rather than in init? I find that initializing the cached index >>> blocks >>> the UI for a very noticeable time. I think the index can be accessed >>> on the main thread only in the -index method and in - >>> cancelForDocumentURL:. >> >> Can you check with Shark or Spin Control to see what's slow? >> Initializing the index on the thread would require avoiding >> NSFileManager, unless it's only the SKIndex creation that's slow. >> > > It seems to spend a lot of time unarchiving (14.5% in Shark). About > half comes from +indexCachePathForDocumentURL: and half from > unarchiving the index we're actually using (I have 2 cached indexes, > the one I use here is significantly larger than the other).
That's what I was afraid of (unarchiving). How big is the actual archive in MB? Mine at work has ~500 files indexed, and I didn't see any slowdown or beachball. > A lot of > time is also spent on some mach_kernel calls, so I don't know > precisely where they come from. The Profile shows something like > vm_map_lookup_entry > vm_map_lookupLocked > vm_fault > trap > > thandler, > ml_set_interrupts_enabled > trap > thandler, and ml_restore > trap > > thandler (all are about 10% each). I don't know if these come from > index creation or unarchiving. Does dataWithContentsOfMappedFile: show up under NSUnarchiver? > So it seems we may gain something from a separate file mapping > document URLs to cached index URLs. NSKeyedUnarchiver is pretty slow. > Still we need to unarchive at least once, so if we could do that on > the thread it could also gain something. It would be interesting to try with NSUnarchiver; I know it's faster than NSKeyedUnarchiver, at least in some situations. I've always wondered if that's why NSPortCoder doesn't support keyed coding? We could also iterate that directory on the thread using UKDirectoryEnumerator (I think) and do all the checking and loading there. Might be easier than tracking and updating another file (and we'd also have to lock that file). >>> Actually I think there may be a problem currently in - >>> cancelForDocumentURL:, because the index can be released/set to NULL >>> both on the main thread and the notification thread. That's >>> dangerous. >> >> The condition lock is used specifically to prevent this; the cancel >> method can't write the index until the thread exits. The index is >> set >> to NULL only in case of an exception, but the lock isn't released >> until the @finally. > > I see now. I find the condition lock slightly confusing. I always have a hard time using NSConditionLock, and the API description is confusing to me. Maybe if you're used to semaphores it makes sense. adam ------------------------------------------------------------------------- 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 Bibdesk-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
