I do see it getting BDSKFileSearch. But the changes in  
BDSKFileSearchIndex give me the beachball. Probably because many  
delegate are send, between threads.

Haven't tried moving sampling and moving the delegate send.

Christiaan

On 20 Jan 2008, at 7:54 PM, Adam R. Maxwell wrote:

> Odd; it's /much/ faster here whether the files are indexed or not,
> probably because it no longer uses waitUntilDone:YES.
>
> Can you try moving the delegate send in the BDSKSearch inside the test
> for time?  That should make it cheaper.  What does sampling show?
>
> On Jan 20, 2008, at 10:49 AM, Christiaan Hofman wrote:
>
>> I get a serious beach ball after these changes.
>>
>> Christiaan
>>
>> On 20 Jan 2008, at 7:22 PM, [EMAIL PROTECTED] wrote:
>>
>>> Revision: 12597
>>>          http://bibdesk.svn.sourceforge.net/bibdesk/?
>>> rev=12597&view=rev
>>> Author:   amaxwell
>>> Date:     2008-01-20 10:22:13 -0800 (Sun, 20 Jan 2008)
>>>
>>> Log Message:
>>> -----------
>>> Throttle search/flush in the BDSKSearch so we can just send
>>> delegate messages in the index.  This gives good progress bar
>>> updates without killing indexing.
>>>
>>> Modified Paths:
>>> --------------
>>>    trunk/bibdesk/BDSKFileSearch.h
>>>    trunk/bibdesk/BDSKFileSearch.m
>>>    trunk/bibdesk/BDSKFileSearchIndex.m
>>>
>>> Modified: trunk/bibdesk/BDSKFileSearch.h
>>> ===================================================================
>>> --- trunk/bibdesk/BDSKFileSearch.h  2008-01-20 16:20:14 UTC (rev
>>> 12596)
>>> +++ trunk/bibdesk/BDSKFileSearch.h  2008-01-20 18:22:13 UTC (rev
>>> 12597)
>>> @@ -66,6 +66,7 @@
>>>
>>>     BDSKSearchPrivateIvars *data;
>>>     id delegate;
>>> +    CFAbsoluteTime lastUpdateTime;
>>> }
>>>
>>> /*
>>>
>>> Modified: trunk/bibdesk/BDSKFileSearch.m
>>> ===================================================================
>>> --- trunk/bibdesk/BDSKFileSearch.m  2008-01-20 16:20:14 UTC (rev
>>> 12596)
>>> +++ trunk/bibdesk/BDSKFileSearch.m  2008-01-20 18:22:13 UTC (rev
>>> 12597)
>>> @@ -87,6 +87,7 @@
>>>
>>>         data = [[BDSKSearchPrivateIvars alloc] init];
>>>         [self setDelegate:aDelegate];
>>> +        lastUpdateTime = CFAbsoluteTimeGetCurrent();
>>>     }
>>>     return self;
>>> }
>>> @@ -125,7 +126,8 @@
>>>
>>>         // if there's a search in progress, we'll cancel it and re-
>>> update
>>>         // if not, we'll notify the delegate with an empty array,
>>> since the index is still working
>>> -        if (NULL != search) {
>>> +        // throttle the cancel/flush to 10 Hz, since that slows
>>> down indexing
>>> +        if (NULL != search && (CFAbsoluteTimeGetCurrent() -
>>> lastUpdateTime) > 0.1) {
>>>             [self cancel];
>>>             [self updateSearchResults];
>>>         }
>>> @@ -170,11 +172,13 @@
>>>     SKIndexRef skIndex = [searchIndex index];
>>>     NSAssert(NULL != skIndex, @"-[BDSKFileSearchIndex index]
>>> returned NULL");
>>>
>>> -    if (SKIndexFlush(skIndex) ==  FALSE) {
>>> +    if (NULL == skIndex || SKIndexFlush(skIndex) ==  FALSE) {
>>>         NSLog(@"failed to flush index %@", searchIndex);
>>>         return;
>>>     }
>>>
>>> +    lastUpdateTime = CFAbsoluteTimeGetCurrent();
>>> +
>>>     SKSearchRef skSearch = SKSearchCreate(skIndex, (CFStringRef)
>>> searchString, options);
>>>     [self setSearch:skSearch];
>>>     CFRelease(skSearch);
>>>
>>> Modified: trunk/bibdesk/BDSKFileSearchIndex.m
>>> ===================================================================
>>> --- trunk/bibdesk/BDSKFileSearchIndex.m     2008-01-20 16:20:14 UTC
>>> (rev 12596)
>>> +++ trunk/bibdesk/BDSKFileSearchIndex.m     2008-01-20 18:22:13 UTC
>>> (rev 12597)
>>> @@ -293,10 +293,6 @@
>>>         id anItem = nil;
>>>         BDSKMultiValueDictionary *indexedIdentifierURLs =
>>> [[[BDSKMultiValueDictionary alloc] init] autorelease];
>>>
>>> -        // see comment later; may need tuning here since this is
>>> much faster than adding new docs to the index
>>> -        const int32_t flushInterval = 100;
>>> -        int32_t countSinceLastFlush = 10;
>>> -
>>>         // update the identifierURLs with the items, find items to
>>> add and URLs to remove
>>>         OSMemoryBarrier();
>>>         while(flags.shouldKeepRunning == 1 && (anItem = [itemEnum
>>> nextObject])) {
>>> @@ -326,16 +322,13 @@
>>>                 @synchronized(self) {
>>>                     progressValue = (numberIndexed /
>>> totalObjectCount) * 100;
>>>                 }
>>> -                if (countSinceLastFlush-- == 0) {
>>> -                    // must update before sending the delegate
>>> message
>>> -                    pthread_rwlock_wrlock(&rwlock);
>>> -                    [identifierURLs
>>> addEntriesFromDictionary:indexedIdentifierURLs];
>>> -                    pthread_rwlock_unlock(&rwlock);
>>> -                    [indexedIdentifierURLs removeAllObjects];
>>> -
>>> -                    [[OFMessageQueue mainQueue]
>>> queueSelectorOnce:@selector(searchIndexDidUpdate) forObject:self
>>> withObject:nil];
>>> -                    countSinceLastFlush = flushInterval;
>>> -                }
>>> +                // must update before sending the delegate message
>>> +                pthread_rwlock_wrlock(&rwlock);
>>> +                [identifierURLs
>>> addEntriesFromDictionary:indexedIdentifierURLs];
>>> +                pthread_rwlock_unlock(&rwlock);
>>> +                [indexedIdentifierURLs removeAllObjects];
>>> +
>>> +                [self performSelectorOnMainThread:@selector
>>> (searchIndexDidUpdate) withObject:nil waitUntilDone:NO];
>>>             }
>>>
>>>             OSMemoryBarrier();
>>> @@ -422,11 +415,7 @@
>>>
>>>     NSEnumerator *enumerator = [items objectEnumerator];
>>>     id anObject = nil;
>>> -
>>> -    // This threshold is sort of arbitrary; for small batches,
>>> frequent updates are better if the delegate has a progress
>>> indicator, but for large batches (initial indexing), it can kill
>>> performance to be continually flushing and searching while indexing.
>>> -    const int32_t flushInterval = [items count] > 20 ? 5 : 1;
>>> -    int32_t countSinceLastFlush = flushInterval;
>>> -
>>> +
>>>     // Use a local pool since initial indexing can use a fair
>>> amount of memory, and it's not released until the thread's run loop
>>> starts
>>>     NSAutoreleasePool *pool = [NSAutoreleasePool new];
>>>
>>> @@ -440,13 +429,10 @@
>>>             progressValue = (numberIndexed / totalObjectCount) *  
>>> 100;
>>>         }
>>>
>>> -        if (countSinceLastFlush-- == 0) {
>>> -            [pool release];
>>> -            pool = [NSAutoreleasePool new];
>>> -
>>> -            [self performSelectorOnMainThread:@selector
>>> (searchIndexDidUpdate) withObject:nil waitUntilDone:NO];
>>> -            countSinceLastFlush = flushInterval;
>>> -        }
>>> +        [pool release];
>>> +        pool = [NSAutoreleasePool new];
>>> +
>>> +        [self performSelectorOnMainThread:@selector
>>> (searchIndexDidUpdate) withObject:nil waitUntilDone:NO];
>>>         OSMemoryBarrier();
>>>     }
>>>
>>>
>>>
>>> This was sent by the SourceForge.net collaborative development
>>> platform, the world's largest Open Source development site.
>>>
>>> -------------------------------------------------------------------- 
>>> --
>>> ---
>>> 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-commit mailing list
>>> [EMAIL PROTECTED]
>>> https://lists.sourceforge.net/lists/listinfo/bibdesk-commit
>>
>>
>> --------------------------------------------------------------------- 
>> ----
>> 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
>
>
> ---------------------------------------------------------------------- 
> ---
> 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


-------------------------------------------------------------------------
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

Reply via email to