Another plea for optimising the Parallel Resource menu

Page 1 of 3 (45 items) 1 2 3 Next >
This post has 44 Replies | 3 Followers

Posts 13368
Forum MVP
Mark Barnes | Forum Activity | Posted: Sun, Sep 26 2010 5:16 PM | Locked

I've been running some tests on the parallel resource menu, as I'm really struggling with it's efficiency. I rely on it heavily in my work flow, and it's a real bottleneck (rather than opening commentaries/dictionaries from a PG or BWS, and have dozens of tabs, I like to select one at a time from the PR menu).

I decided to run some benchmarks with Process Monitor running. I know very well that gives me only the smallest insight into what Logos is actually doing, and lots of my guesses will be quite wrong. I'm also certain that some things that seem daft to end-users have perfectly logical and sensible explanations.

Nevertheless, there seems to be a huge amount of inefficiency in the parallel resource look up given that there are indexes to all the headwords.

This is for created a PR menu from Enuma Elish in AYBD, but it wouldn't really matter. (I've run this test several times before benchmarking, so this is best case scenario - my Windows cache is well and truly primed.)

  1. First, Logos searches through each of my collections which have "Show in Parallel Resources" to see whether AYBD appears in any of them. Time taken is 2.6691 seconds.
  2. Second, Logos queries catalog.lxn, which seems to be for word-stemming (takes about 0.2 seconds).
  3. Third, Logos gets a list of all resources with the same type as the one we're looking up the PRS for (I'm presuming this). This proved not to be true (see inefficiency 3 below).
  4. Fourth, for every resource with this type
    • Logos access the resource and reads several thousand bytes of data. Time taken = 0.005s.
    • Logos queries the index (these are the .mstidx files). Time taken = 0.005s.
  5. Fifth, if the resource is found in the index, the resource is accessed again = 0.004s
  6. Sixth, the Library Catalog is accessed, probably to get cover images and book names. This takes 0.6 seconds.
  7. Seventh, a series of apparently random books are all accessed. In this test, it included several volumes of Holman's commentaries, the Logos Hymnal, 1000 illustrations, (see inefficiency 3 below)

Likely Inefficiency #1: During stage 1, nested queries aren't cached, so several queries run multiple times. In my case that means 14 unnecessary queries taking a total time of 1.357s (50.8% time wasted).

Likely Inefficiency #2: Most of the resources don't contain a reference to be looked up. Yet despite this the resource is always access, even before the index is checked. Why? 0.005s doesn't seem like very much, but if you have 1,300 commentaries, as I do that's 6.5 seconds seemingly wasted.

Likely Inefficiency #3: During stage 7, dozens of resources are looked up, even though they'll never appear in the PRS. They contain a headword index, but they're of the wrong type (monographs or commentaries) so they'll never appear in the list. If they won't show up, why bother searching them?

Likely Inefficiency #4: None of this is cached, so if I do a lookup on the same headword from a different resource a few seconds later the whole process will run again. But surely there's no need. If the headword is the same, the results will be the same. Likewise if I do a lookup on a different headword from the same resource, then steps 1 and 3, and part of step 6 can be cached.

 

Like I said, I could be barking up the wrong tree entirely, and if so I'm sorry. But this is born out of frustration of a great feature that is frustratingly slow, and for which I long to improve.

Posts 9101
Forum MVP
Mark Smith | Forum Activity | Replied: Sun, Sep 26 2010 5:59 PM | Locked

Well I'm impressed with the analysis at this point and your conclusions. I agree that there has to be unnecessary work being done, esp. when you look up the same headword in another resource. Caching would seem to be the answer for that. A second look-up should be almost instantaneous.

I would think what is happening first could also be helped through an index of one's collections being searched rather than a fresh search each time one accesses parallel resources.

I do hope Logos will find a way to make this operation much faster. Like you I use this feature frequently and often my run times are significantly longer than what you are experiencing.

Pastor, North Park Baptist Church

Bridgeport, CT USA

Posts 18754
Rosie Perera | Forum Activity | Replied: Sun, Sep 26 2010 6:22 PM | Locked

I agree this needs to be sped up. I would use this feature more if it were faster.

Posts 2925
Forum MVP
Jacob Hantla | Forum Activity | Replied: Sun, Sep 26 2010 6:28 PM | Locked

I agree with the need for more speed. I actually usually just access the parallel resource I want manually from "My Library" because of the slowness of parallel resources.

Jacob Hantla
Pastor/Elder, Grace Bible Church
gbcaz.org

Posts 13368
Forum MVP
Mark Barnes | Forum Activity | Replied: Sun, Sep 26 2010 8:05 PM | Locked

I've just created a database of all my headwords so I could run speed tests. If Logos created a single headword index (instead of one index per resource as currently), then a search for all resources matching the headword could be reduced to around 0.3s on my system (and 0.001 when cached). You'd still need to search the collections, and get the library data from the catalog, and sort by prioritisation, but each of those database calls should be less quicker than the initial search. These tests prove (I think!) that it's quite feasible to get the whole menu up in 1-2 seconds, even with a very large library.

Posts 179
Trey Selman | Forum Activity | Replied: Sun, Sep 26 2010 8:06 PM | Locked

Mark, thanks for taking the time to do this analysis.

I, too, use this feature quite heavily and hope to see it optimized.

For my work-flow, this feature exhibits the greatest amount of sluggish performance.

How much more wonderful it would be if the momentary and light frustration of the sluggish performance was gone!

Posts 25096
Forum MVP
Dave Hooton | Forum Activity | Replied: Sun, Sep 26 2010 9:18 PM | Locked

Mark Barnes:
I'm really struggling with it's efficiency

If you look at your PRS in some instances the resource has no value for the reference whereas All Parallel Resources will not include that resource! I posted a couple of bug reports and I'm still puzzled by this response!

Mark Barnes:
But this is born out of frustration of a great feature that is frustratingly slow,

I have 17 collections of which 8 are PRS so I get acceptable performance (2s) most of the time. But it can be an unacceptable 9s when a particular index (eg. bible) is used for the first time (see Laptop specs below). With better performance I would not be artificially limiting the number of PRS.

 

Dave
===

Windows 10 & Android 8

Posts 13368
Forum MVP
Mark Barnes | Forum Activity | Replied: Mon, Sep 27 2010 2:16 AM | Locked

Dave Hooton:
I'm still puzzled by this response!

What's really puzzling about that response is the situation Melissa wants to avoid is exactly the way it is currently designed! (And, of course, if it can do it for the All Parallel Resource menu it can do it for a collections menu.)

Posts 5613
Todd Phillips | Forum Activity | Replied: Mon, Sep 27 2010 5:23 AM | Locked

Mark Barnes:
If Logos created a single headword index (instead of one index per resource as currently), then a search for all resources matching the headword could be reduced to around 0.3s on my system (and 0.001 when cached).

If they did this, then they would also be able to provide us with a true headword search in the search window, which we want to be able to do.

Wiki Links: Enabling Logging / Detailed Search Help - MacBook Pro (2014), ThinkPad E570

Posts 3809
spitzerpl | Forum Activity | Replied: Mon, Sep 27 2010 5:30 AM | Locked

Rosie Perera:

I agree this needs to be sped up. I would use this feature more if it were faster.

Same here. I see the value but never use it because of performance.

Posts 4508
Robert Pavich | Forum Activity | Replied: Mon, Sep 27 2010 5:46 AM | Locked

Philip Spitzer:
Same here. I see the value but never use it because of performance.

Ditto

Robert Pavich

For help go to the Wiki: http://wiki.logos.com/Table_of_Contents__

Posts 4077
Melissa Snyder | Forum Activity | Replied: Mon, Sep 27 2010 8:26 AM | Locked

The case to optimize parallel resource sets is still open. I've added a link to this thread to it.

Posts 1228
Ron | Forum Activity | Replied: Mon, Sep 27 2010 10:05 AM | Locked

Philip Spitzer:

Rosie Perera:

I agree this needs to be sped up. I would use this feature more if it were faster.

Same here. I see the value but never use it because of performance.

Yes Same situation with me.

Posts 13368
Forum MVP
Mark Barnes | Forum Activity | Replied: Mon, Sep 27 2010 11:50 AM | Locked

Mark Barnes:
Likely Inefficiency #3: During stage 7, dozens of resources are looked up, even though they'll never appear in the PRS. They contain a headword index, but they're of the wrong type (monographs or commentaries) so they'll never appear in the list. If they won't show up, why bother searching them?

I've realised I'm wrong about this. Non-dictionaries do appear in headword look-ups if they're appropriated indexed (e.g. like the Africa Bible Commentary). Is this new?

Posts 13368
Forum MVP
Mark Barnes | Forum Activity | Replied: Mon, Sep 27 2010 1:00 PM | Locked

Philip Spitzer:
I see the value but never use it because of performance.

Just a note of encouragement. The more you use the feature, the quicker it gets - particularly if you have lots of RAM and a fast HDD.

In my experience commentary lookups are the slowest (simply because we have more commentaries than dictionaries, and probably because differing verse ranges make verse matching is fuzzier than headword matching).

Where I have many commentaries on a Bible book, I can find the first time I use the PRS menu take more than 1 minute. But subsequent usages are usually down around the 7-10 seconds mark. Still unnecessarily slow and frustrating, but perhaps worth persevering with.

Posts 25096
Forum MVP
Dave Hooton | Forum Activity | Replied: Mon, Sep 27 2010 3:54 PM | Locked

Mark Barnes:
Just a note of encouragement. The more you use the feature, the quicker it gets

It also becomes quicker by getting more accurate! Here's my PRS Lexicons on a lookup of G5467  in  ESL (Enhanced Strong's):-

All Parallel Resources lists only the resources that contain the reference (the New American Standard Dictionary is not in my Collection). My PRS lists the 11 Greek lexicons from the collection of 18, so it has done some filtering! However, 6 lexicons don't even have an Index for Strong's Greek.

After 4 or 5 repeats my PRS resembles reality except for the inclusion of TDNT, but it should be correct first time.

Dave
===

Windows 10 & Android 8

Posts 25096
Forum MVP
Dave Hooton | Forum Activity | Replied: Mon, Sep 27 2010 4:56 PM | Locked

Mark Barnes:
Fourth, for every resource with this type

Needs amending in light of 3 (not the same types)

Mark Barnes:
Seventh, a series of apparently random books are all accessed. In this test, it included several volumes of Holman's commentaries, the Logos Hymnal, 1000 illustrations, (see inefficiency 3 below)

What is Stage 7 now?

Mark Barnes:
Likely Inefficiency #3: During stage 7, dozens of resources are looked up, even though they'll never appear in the PRS. They contain a headword index, but they're of the wrong type (monographs or commentaries) so they'll never appear in the list. If they won't show up, why bother searching them?

As I've shown resources that don't even have an index for the reference are included in the PRS. Resource type is not the issue because my collections will include different types having the same Index ie. data type.  My commentaries include type:Bible Notes, and they should be included if they have the reference.

Dave
===

Windows 10 & Android 8

Posts 707
Russ Quinn | Forum Activity | Replied: Mon, Sep 27 2010 7:15 PM | Locked

Thanks, Mark for your thorough analysis.

I'll have to leave the finer points of how all of this works to you and Dave.

I don't understand all that goes on under the hood enough to offer advice on actual optimizations.

However, I wonder if there are ways to at least change the user's perception of the speed of this feature.

Two suggestions in particular:

1. Is there a way to execute the search as a background process in anticipation of clicking the button instead of waiting on the user to click the button?
Perhaps the list could pre-populate for the current reference or headword whenever scrolling pauses for 5 seconds or so?

2. Could the results of the search be listed in the resource window as they are found instead of waiting for the entire search to be completed before any of the relevant resources are displayed? 

Don't get me wrong . . . I'm all for optimizing the process to remove whatever inefficiencies are really there.
But most of the time, I feel like I am waiting for it to complete a search for more resources than I will probably use.

Posts 406
Fred Greco | Forum Activity | Replied: Mon, Sep 27 2010 8:11 PM | Locked

Ron Keyston Jr:

Philip Spitzer:

Rosie Perera:

I agree this needs to be sped up. I would use this feature more if it were faster.

Same here. I see the value but never use it because of performance.

Yes Same situation with me.

I appreciate Mark's hard work in trying to figure this out (it is way beyond me), but these comments are the key for Logos.  I also do not use this feature, even though it would be of great benefit almost every time I use Logos. It makes collections more usable, workspaces cleaner, RAM usage less (since less tabs need to be open) and makes commentaries much more valuable.

That is, it would, if it was at all usable.  It is maddening to be working on a passage, reading one commentary, and have to click and wait like two minutes for the spinning wheel.  It might even encourage users to buy more commentaries, as they would be more usable.

Right now, this feature might as well be removed. That is how bad it operates, IMO.

Fred Greco
Senior Pastor, Christ Church PCA, Katy, TX
Windows 10 64-bit; Logos 7.1 SR-2 (Reformed Platinum)

Posts 59
Westie | Forum Activity | Replied: Mon, Sep 27 2010 10:47 PM | Locked

Fred Greco:

That is, it would, if it was at all usable.  It is maddening to be working on a passage, reading one commentary, and have to click and wait like two minutes for the spinning wheel.  It might even encourage users to buy more commentaries, as they would be more usable.

This is one of the strengths of L3, and why I still use L3.  When I know that I will be reviewing various commentaries, dictionaries  or lexicons, I use L3 because it is faster and easier.  I feel that I have better access to books in L3, than I do in L4.  I like L4, but this area is a real weakness for people that have a large library.   I hope this changes.

Mark

Page 1 of 3 (45 items) 1 2 3 Next > | RSS