On Jan 20, 2008, at 1:07 PM, Christiaan Hofman wrote: > > > On Jan 20, 2008 9:05 PM, Christiaan Hofman <[EMAIL PROTECTED]> wrote: > > On 20 Jan 2008, at 8:27 PM, Adam R. Maxwell wrote: > > > I see...try changing the time interval in the search to 0.5 or so > > instead of 0.1. It's calling -updateSearchResults too frequently, > > which is what it was supposed to avoid. > > > > It looks like sha1Signature is probably using a lot of memory, as > > well, since it's reading entire files into memory. We should be > able > > to avoid that by using NSFileHandle. > > > > That's not in OF though. And would it make a difference? I think sha1 > takes the whole data into account, and it should (in case something > is added to the end).
See if it's any faster with the stuff I just checked in. We're still taking the entire file into account, but it should be faster with large files since we're not trying to malloc the entire thing and get its byte pointer. > If I bring back the OFMessageQueue in BDSKFileSearchIndex the beach > ball is gone during the initial step, and comes back after that. So > should we perhaps always queue the delegate methods, as well as > checking for time interval? So it's just piling up the performSelectorOnMainThread: requests, then? I was hoping that if we base the updating on time it would give us consistent results across more hardware. I guess count could be factored in as well, but it seems hard to tune. If queueing solves the problem, that's cool (as long as the last update problem you mention can be solved). Another idea might be to have a separate progress delegate method now, since the initial updating phase isn't strictly tied to searching. Delegate updates during signatures are probably what's killing it. > > Also the problem with the last update of course still remains. Does the didFinish step handle that? ------------------------------------------------------------------------- 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
