Search time anomaly

Matt

Hi all,  I ran a search using the search panel using the search phrase 'r?se' on my 'Entire Library'.  It took 52.60s to return 41,234 results.

That seemed very slow, so I ran it again, and achieved a much faster time.  It was so much faster, that I figured that something had been cached, so I restarted Logos and ran the query again.  This time, it was just as fast.

 

So, I next thought "I wonder if Logos is using lazy evaluation in their indexes."  So, the next logical step was to try the same experiment on another computer, which I did.  First run:

 

Second run (again, after a restart of Logos):

 

As is readily apparent, the pattern is the same on two distinct machines. 

On a Macintosh which has Alpha 13a installed on it, which is not fully indexed (indexing keeps running, then stopping), I get different behavior, in that the first time it runs is the same as the next time it runs.

(The slower performance on the Mac is expected as it's a dual-core with a slower drive, and overall lower hardware specs.)

I noted on the Windows systems, that during the long initial delay, there was almost no CPU activity, but there was heavy I/O.  I don't think of this as a bug, but considering that the backend on Mac is supposedly C# running under mono, one would expect the behavior of the two to be similar (i.e. this doesn't appear to be related at all to graphically rendering the results).

Does Logos have an comment on this, such as general guidelines as to which kind of queries will have an initial cost to them, so the end-user doesn't think there's something wrong with the program or their computer?

Thanks,

Matt

 

Bradley Grainger (Logos)

Does Logos have an comment on this, such as general guidelines as to which kind of queries will have an initial cost to them, so the end-user doesn't think there's something wrong with the program or their computer?

The current implementation of any wildcard search (except for a prefix search, e.g., "ras*") will scan the entire term list looking for matches. (In this case, we could optimise it to look only at words beginning with "r", but we haven't done that yet.)

Loading the term list into memory is incredibly I/O intensive and very slow (compared to actually performing the search for the words that match the wildcard). Assuming you have enough free RAM, Windows will cache that data because it has been accessed recently; this is why the second search is so much faster.

In general, you can expect wildcard searches to be slower.