I just timed it: it takes 27 seconds for this dropdown to populate on my computer. Even the second time it still takes 10. That is far too long!
I guess you have in excess of 4000 resources, but how many collections have you ticked for use in Parallel Resources and how many collections appear in your 27s example (a screen shot would help).
Tried with with several resources from varied collections. With 7k+ resources. All took less than 5 seconds to fully populate.
Mac OS 10.8.4 27" iMac 3.4 GHz i7 with 24 GB RAM. What are your specs?
I have a lot of Collections, and I have well over 10,000 resources. Maybe this is a Mac issue, as on Win 7 x64, I pulled up Job 3.1 in a Bible, opened NAC:Job which belongs to two collections which will appear in parallel resources dropdown, and it came up in less than 3 seconds.
Maybe this is a Mac issue
Not a Mac issue. See my post just above yours.
fgh: Do you have a lot of collections selected to show in parallel resources? Other than that, can't think of a cause.
how many collections appear in your 27s example (a screen shot would help)
Only for you, since you like screenshots so much[:D]:
What are your specs?
Look in my signature.[;)]
I have the same symptoms that fgh has. I'm on a PC laptop, running Windows 7 with an I7-2670 processor and 8GB of memory. I have 4,300 resources in my library and about 50 collections marked to show in parallel resources. It used to work fine, but has been slow since around or a little after the first 5.1 beta.
I often have the same problem when selecting a Bible in a Bible search and also when selecting a Bible in the Text Comparison.
I have the same symptoms that fgh has. I'm on a PC laptop, running Windows 7 with an I7-2670 processor
Very interesting! That means no one can blame my old Mac.
I have the same symptoms that fgh has. I'm on a PC laptop, running Windows 7 with an I7-2670 processor Very interesting! That means no one can blame my old Mac.
And I don't think it is related to v5.1 as I get my bible parallel resources inside 3 seconds after opening a tab. It would be worthwhile having a look at your logos.log immediately after reproducing your issue (start Logos with Command key to generate it).
It would be worthwhile having a look at your logos.log immediately after reproducing your issue
Dave, would that be the LogosError.log file from C:\Users\Tim\Documents\Logos Log Files on my PC? I'll try to post it here tonight.
Dave, would that be the LogosError.log
No - it's the Logos.log file! It has to be generated in the way I indicated (hold CTRL key down as you start Logos in Windows).
Log file attached.
3173.Logos.log
Resource collections that use "*" in their filter string are extremely expensive to evaluate. You have a collection with the rule "* ANDNOT type:("Bible Commentary","Bible Notes","Bible")" that takes 27s to evaluate in the current version of Logos 5.
You will probably see a dramatic performance increase if you replace "*" with "rating:>=0".
Thank you, Bradley. I found two collections with an asterisk in them. Changed both and performance is much better.
Bradley,
This further makes the case for a dedicated "not" operator. It's completely artificial to have to explicitly include all resources with some kind of wildcard expression (either "*" or "rating:>=0") simply to be able to get to the "ANDNOT" operator.
Either "NOT type:("Bible Commentary","Bible Notes","Bible")" or something like "type!:("Bible Commentary","Bible Notes","Bible")" (not the exclamation mark before the colon) ought to achieve the intended resuls without the superfluous universal expression.
Donnie
case for a dedicated "not" operator.
