Bug 4.0c RC3: Another 'freezing' problem in RC3

Like many users I have some large collections that include search strings like rating:>=0. I'm finding that in recent builds of Logos these are causing freezes. For example, I have one string rating:>=0 ANDNOT (type:bible). When I choose that collection from the search drop down. The log doesn't time how long these searches take (thought it would be good if it did), but I estimate my freeze lasted for around 20 seconds. This search result isn't cached, so I get these delays very frequently.

Interestingly, when I load the collection in the collections window, I get nearly instant results.

Find more posts tagged with

Comments

Todd Phillips

I can confirm this behavior, except my freezes aren't quite as long. When I selected my "All but Bibles" collection in the search window, it hung for about 5-8 seconds--still significant.

JimTowler

... that include search strings like rating:>=0

Mark,

I don't want this to distract from the point of your post, but why search for x>=0 when it matches ALL records?

I'm wondering why you would want to include that portion. Clearly I'm missing some important aspect.

Thanks.

Mark Barnes

https://community.logos.com/discussion/comment/127726#Comment_127726

why search for x>=0 when it matches ALL records

It's because there's not a NOT operator, only an ANDNOT. So we can't search for NOT(type:bible), we have to search for rating:>=0 ANDNOT type:bible

Todd Phillips

https://community.logos.com/discussion/comment/127724#Comment_127724

I can confirm this behavior,
except my freezes aren't quite as long. When I selected my "All but
Bibles" collection in the search window, it hung for about 5-8
seconds--still significant.

BTW, my collection
definition is slightly different from Mark's. I used the minus sign instead of ANDNOT:

rating:>=0 -type:bible

JimTowler

https://community.logos.com/discussion/comment/127742#Comment_127742

Surely not!

So really, we need a NOT, and NOT having to use (some kind of ALL) ANDNOT (type:bible).

Until then, we need to know what the best (some kind of ALL) to use. Maybe the rating:>=0 as its a numeric field at face value.

Dave Hooton

https://community.logos.com/discussion/comment/127744#Comment_127744

So really, we need a NOT, and NOT having to use (some kind of ALL) ANDNOT (type:bible).

Until then, we need to know what the best (some kind of ALL) to use. Maybe the rating:>=0 as its a numeric field at face value.

It would be good to have a unary NOT, but not essential.

rating:>=0 is accepted as defining ALL resources.

Mark Barnes

https://community.logos.com/discussion/comment/127929#Comment_127929

rating:>=0 is accepted as defining ALL resources.

Except in the context of this thread, it's quite likely that NOT would be faster.

Dave Hooton

https://community.logos.com/discussion/comment/127935#Comment_127935

Except in the context of this thread, it's quite likely that NOT would be faster.

Yes, that was behind my response.

Melissa Snyder

Mark ~ I've submitted a report on this. I found that a collection of over 10,000 resources hung the app for about 30 secs, but with a collection of almost 6,000 resources the app was available almost instantaneously.

Todd Phillips

https://community.logos.com/discussion/comment/127999#Comment_127999

Mark ~ I've submitted a report on this. I found that a collection of over 10,000 resources hung the app for about 30 secs, but with a collection of almost 6,000 resources the app was available almost instantaneously.

I have 1905 resources in my active library (i.e. not hidden), and I experienced the 5-8 second hang I described above (which I wouldn't equate to almost instantaneous).

Mark Barnes

https://community.logos.com/discussion/comment/127999#Comment_127999

Interesting. Here's my experience, with some collections created as a test:

Name	String	Num resources	Time taken
Everything	rating:<=5	3,994	20-30s
Not Bibles	rating:>=0 ANDNOT (type:bible)	3,765	20-30s
Not rated highly	rating:<4	3,423	instant
Not monographs	rating:<=5 ANDNOT type:(monograph)	2,619	instant

So my tipping point is considerably lower than yours. My hunch would be that there's a caching issue, and perhaps that the query is to big to cache in memory. Perhaps the devs could confirm.

Melissa Snyder

https://community.logos.com/discussion/comment/128019#Comment_128019

So my tipping point is considerably lower than yours. My hunch would be that there's a caching issue, and perhaps that the query is to big to cache in memory. Perhaps the devs could confirm.

There will be a fix for this in the first 4.0c service release (SR).

Mark Barnes

https://community.logos.com/discussion/comment/128056#Comment_128056

Excellent! Thank you.