Bug: ESV non-responsive when opening for first time

This has been happening for some time with v7.x. After opening Logos to my modest layout (below) and clicking the ESV tab there is a delay, Logos becomes non-responding and when it finally opens it has swapped places with BKC.

1362.ESV slow response.zip

Visual filters:

Addressee
Corr Selection
Emph Active Lemma
Speaker Labels
1x Note file (small)
1x Basic search VF on Translator's Note field

Find more posts tagged with

Comments

Keep Smiling 4 Jesus :)

Concur opening resource(s) with Visual Filters enabled is unresponsive plus has no indication that visual filter highlighting is in process. At times, dream about a banner similar to Search when Indexer is running about Search results being incomplete, which would help show Logos 7 is busy searching and applying visual filters (and have banner disappear when done).

Keep Smiling [:)]

Bradley Grainger (Logos)

Firstly, there appears to be a huge amount of background activity going on:

Resource updates
Metadata updates
Document indexing

This is all causing a lot of contention on the disk. (If this is happening every single time you run the application, then something is wrong and we need to dig into that more.)

The performance problem with the ESV may be related to visual filters. Firstly, try disabling non-search-based Visual Filters, such as reported speech. Also try turning off the reverse interlinear ribbon (or inline display) if you have those on. Does this improve performance at all?

Secondly, we can look into how much of a problem search-based VFs are. These are evaluated on a background thread so they shouldn't freeze the UI, but they may cause disk contention that blocks UI operations. The VFs that seem particularly slow are:

you NOTEQUALS <LN 1-93>
he NOTEQUALS <LN 1-93>
"signs of the end", "nation will rise", "hear of war", "false christ", earthquakes, betray, hatred, abomination
lemma:εἰ@CAC BEFORE 7 words @V??I
lemma:ἐάν@CAC BEFORE 6 words @V??S
lemma:εἰ@CAC BEFORE 6 words @V??O
<Bible jn 3:16>
"some manuscripts add", "some manuscripts insert", "some manuscripts omit"
"son of man" NEAR (clouds, power, glory)
{Section <PreachingTheme Marriage>}

It's not sufficient to simply uncheck these on the VF menu; you need to delete them (or change them to apply to a resource other than the ESV). Does doing that improve anything?

Dave Hooton

https://community.logos.com/discussion/comment/866408#Comment_866408

This is all causing a lot of contention on the disk. (If this is happening every single time you run the application, then something is wrong and we need to dig into that more.)

It doesn't seem to be an issue when the layout is loaded with ESV tab open

2021.Load with ESV open.log

This is the most recent attempt to open ESV from within the layout, without an issue.

2630.Logos.log

The main point is that the "not responding" issues happens frequently whereas it had not been a problem with Logos 6 - the search VF's have not changed.

It's not sufficient to simply uncheck these on the VF menu; you need to delete them (or change them to apply to a resource other than the ESV).

I'll respond to this ASAP.

Dave Hooton

https://community.logos.com/discussion/comment/866415#Comment_866415

It's not sufficient to simply uncheck these on the VF menu; you need to delete them (or change them to apply to a resource other than the ESV).

6558.Open ESV.zip

One log shows opening ESV with VF's and no issue. The other shows opening ESV with no VF's (response time similar to previous case).

Bradley Grainger (Logos)

https://community.logos.com/discussion/comment/866574#Comment_866574

If I'm understanding you correctly, in all four logs you posted (two on each reply), the "ESV non-responsive" issue did not occur; is that correct?

If that's the case, then it seems that the number of enabled VFs has little to do with the performance of opening the resource panel. Instead, the problem may have been all the background work that I mentioned in my previous reply. And if you've been able to open the ESV a number of times without problems, then is it the case that the issue occurs infrequently?

Dave Hooton

https://community.logos.com/discussion/comment/866580#Comment_866580

It happened frequently in v7 prior to creating this problem report, but never in v5/6.

Since creating this report it has happened a few times. The period that applies to these logs is too short to conclude that the issue occurs infrequently.

Dave Hooton

https://community.logos.com/discussion/comment/866585#Comment_866585

The issue definitely arises during a download when 98%+ disk activity is reported, or whenever the system is responsible for that disk activity.