Still unacceptably slow: populating Bible Search dropdown

Rosie, you proved your case. Interestingly, you do not have an accent, at least not one that I could pick up on. [:)]

I noticed it also, guess I just learned to tolerate it.

https://community.logos.com/discussion/comment/513205#Comment_513205

Interestingly, you do not have an accent, at least not one that I could pick up on.

What sort of accent were you expecting? Canadian, eh? I grew up in Western Massachusetts (far enough away from Boston to not have a Boston accent) and lived in Seattle for many years (which doesn't really have its own strong recognizable accent perhaps because it's made up of so many people from elsewhere) before moving up to Vancouver. So I've probably got a mixture of various accents. Everyone has an accent of some sort. It's just all relative to who is listening to it.

I will not learn to tolerate things that I know Logos developers can do better at, as that would be complacency and complicity in mediocrity. Having been a developer before, I know there is a way to improve this significantly, and I recommended it in the video. Compute and cache the contents of the dropdown ahead of time, so that you don't have to compute it each time the user drops the menu down. I hope Bradley is listening and takes this seriously. This has been an issue for so long, and their attempts to "optimize" it in the past have not done the obvious caching solution, or it would be remarkably fast.

David Thomas

Rosie,

First, I agree that the performance you documented is unacceptable.

On my hardware (a Surface Pro) which is much less than your benchmark, it is almost immediate. Could it be the size of our libraries or the number of collections we have? I only have 1542 resources in my Library. Here is a screencast of my experience. [I am NOT trying to deny that your experience is painful, just to show that other users have different experience with this same feature]

http://screencast.com/t/YEyF6sGNGw6

David

Rosie, what is your Windows Experience Index? Mine is 5.9.

https://community.logos.com/discussion/comment/513217#Comment_513217

David that is instant. I have a library of 5400 and several collections.

Jack Caviness

So you have to sit there and stare at it through all the agonizingly slow 25 seconds or so. Arggh!

Mine populates almost instantly with 7k resources. I know that is less than you have, but the difference should not be that great. Maybe Logos finally optimized the Mac version [:D] Gives us an opportunity to gloat for a change [H]

https://community.logos.com/discussion/comment/513217#Comment_513217

On my hardware (a Surface Pro) which is much less than your benchmark, it is almost immediate. Could it be the size of our libraries or the number of collections we have? I only have 1542 resources in my Library. Here is a screencast of my experience. [I am NOT trying to deny that your experience is painful, just to show that other users have different experience with this same feature]

Yes, no doubt it is because of the size of my Library (11,044 resources unhidden) and more important the number of collections I have (280). In fact, Bradley has told me before that the number of collections I have is probably the culprit (at that time, it was only taking 13 seconds to populate this menu for me; it's double that now). But I don't think I should have to limit the number of collections I have in order for a very common task in Logos to be reasonably fast. Logos is made for power users, and I'm a power user, and I want to use it to the max. I will probably continue creating more collections to suit my needs. I don't want that to cripple the software.

Bradley also has replied to my request that they cache the info ahead of time in the past:

That info should be cached ahead of time, as it's going to be the same every time I drop down the list (unless I've edited some collections).

When? (Should we make startup 14s slower?)

No, I don't say say it should be done at startup, but rather during idle time sometime after startup. And you don't have to do all of it at once. I'm not sure Logos even has the concept of idle time processes. When the user is just sitting there reading something on the screen, grab some seconds and do something, even if it's just part of something. In Word, we had an idle loop that could be entered and exited at any time, interrupted immediately if the user initiated any input (mouse or keyboard), but entered again if they were idle for more than a second or so. And we saved our state so we could pick up where we left off, computing whatever background tasks we could that would speed up the user's experience with the software. A win-win! Once again I am begging and pleading with Logos to do something like this. I know they don't want to do something that complicated to fix a problem that only affects a small percentage of users, but it will pay off bigtime in the future. Once they implement an idle processing loop, they can easily speed up performance of all kinds of things.

Another thing Bradley said could be causing this is PB Bibles, but I've rebuilt all my PBs since the bug he referred to here was fixed:

PB Bibles are the culprit. (Some of the automatically-generated metadata is extremely poor, which causes this performance problem when it's read back from catalog.db.) You'll probably have to rebuild all the Bibles (once) to regenerate this metadata once the bug is fixed.

I'm glad you were able to figure out what was causing the problem. I'd be happy to rebuild my PB Bible once this is fixed.

The bug affects any resource with milestones (including page numbers); unfortunately, you'll probably need to rebuild every affected resource to completely fix this performance problem. (Without profiling, it's hard for me to know exactly what areas of the app will be affected, and by how much, but it would probably have a negative impact on many components that query the Library Catalog.)

Rosie, what is your Windows Experience Index? Mine is 5.9.

My Windows Experience Index is 7.7. My Novabench score is 1772.

David Thomas

https://community.logos.com/discussion/comment/513232#Comment_513232

I'm a power user, and I want to use it to the max. I will probably continue creating more collections to suit my needs. I don't want that to cripple the software.

I concur that this program ought to be able to handle anything that power users throw at it. [Y]

tom

It currently takes 25+ seconds to populate the dropdown the first time

I wish mine was that fast. I do have an older computer, and it took my computer 3 minutes and 53.3 seconds.

My use of Logos dropped tremendously when L4 came out, and this is one reason - it is SLOW!!!!!!!

David P. Moore

It currently takes 25+ seconds to populate the dropdown the first time,

I pointed this out on Jan 22nd: http://community.logos.com/forums/t/65022.aspx and a few days later Bradley Grainger said to expect an improvement in the next release, but like you I don't think there has been much of one. I just timed mine at 40 seconds on an i7 2.4GHz laptop with 8BG memory and a 5.9 Experience index.

https://community.logos.com/discussion/comment/513244#Comment_513244

I'm a power user, and I want to use it to the max. I will probably continue creating more collections to suit my needs. I don't want that to cripple the software.

I concur that this program ought to be able to handle anything that power users throw at it.

Yeah, Logos should have an internal power user account that they use for benchmarking that has tons of resources and collections and user documents and highlighting and everything else you can possibly do in Logos.

https://community.logos.com/discussion/comment/513258#Comment_513258

Yeah, Logos should have an internal power user account that they use for benchmarking that has tons of resources and collections and user documents and highlighting and everything else you can possibly do in Logo

I concur. When it works well on theirs, imagine who well it will work on ours.

https://community.logos.com/discussion/comment/513271#Comment_513271

Yeah, Logos should have an internal power user account that they use for benchmarking that has tons of resources and collections and user documents and highlighting and everything else you can possibly do in Logo

I concur. When it works well on theirs, imagine who well it will work on ours.

Reminds me of a guy in our development team when I was working on Microsoft Money, the legendary Doug Klunder, who had been lead software engineer on Excel. He was so obsessed with making the performance good enough for all our users, that he used to use a development machine that was two generations older than what all the rest of us were using (he was using a 286 PC-AT when the rest of us had 486's). If it wasn't fast enough for him on that machine, it wasn't fast enough. That was what I call dedication to users, empathizing with them. Money was the fastest product I ever worked on there. And I learned some of my best efficient program skills from working with Doug (and from reading the classic Writing Efficient Programs by Jon Louis Bentley).

Bradley Grainger (Logos)

Hi Rosie,

Thanks for posting the screencast. Do you actually end up picking a collection from the drop-down list frequently, or do you more typically pick a single Bible? I'm wondering if it would be useful to make individual Bibles available in the list before all the collections were loaded.

and nearly 20 seconds subsequent times, on my super fast machine. ... And it should be nearly instantaneous on subsequent times.

I'm not able to reproduce this problem. I have 500+ collections and the drop-down opens in under a second for me the second time I open it. (It's only slow the first time.) But perhaps solving the initial delay will fix the subsequent delay too?

I don't see why you can't cache the info for this dropdown during idle time sometime shortly after Logos boots up. It's not going to change unless I edit my collections. And if it does change, you can always flag it to be recomputed next time it's needed, or during another idle opportunity.

This is one of the biggest things holding me back from being productive in Logos. Please look into optimizing it properly once and for all. Thanks!

Yes, I'm sure some caching can be added to solve this problem (https://twitter.com/reeses/status/157344234339446784).

https://community.logos.com/discussion/comment/513356#Comment_513356

Do you actually end up picking a collection from the drop-down list frequently, or do you more typically pick a single Bible?

Bradley, I usually pick a single Bible. Mine are not in collections, but my time is the same as Rosie's.

I'm wondering if it would be useful to make individual Bibles available in the list before all the collections were loaded.

Yes, please do. If switching to a Bible, why do the collections come up?

https://community.logos.com/discussion/comment/513360#Comment_513360

This is a funny problem to narrow down, hopefully Bradley has seen it in action. I have a very large library over 10,000, and I have 239 collections. I just tried right now, and the Bible search dropdown populates in about 2 seconds - very fast. I was going to video it! But a number of times in the last few weeks it will take almost 15 seconds. This is on a laptop with a Windows Experience Index of 7.7.

Donnie Hale

https://community.logos.com/discussion/comment/513356#Comment_513356

I'm not able to reproduce this problem. I have 500+ collections and the drop-down opens in under a second for me the second time I open it. (It's only slow the first time.) But perhaps solving the initial delay will fix the subsequent delay too?

I'm not sure if this info is helpful or not, but the dropdown is very slow for me, too. I have about 5K resources, but fewer than 30 collections. Given the disparity of experiences of people contributing in this thread, it seems to me that the issue is not strictly about number of resources or number of collections. Some other variable is impacting response time.

BTW, I have a Core i7 (1st gen) w/ 12gb RAM and L5 running on a Samsung 840 Pro SSD.

Donnie

Kevin Taylor

https://community.logos.com/discussion/comment/513374#Comment_513374

Rosie, this is quite interesting. Seems that there is more than meets the eye here as far as the performance results.

Your chipset is a monster, no question there although I'm not sure how much use Logos makes of the multi-threading that makes the i7 980X shine. I get search results in under 2 seconds running the same parameters granted I have much less resources(5,043) and collections than you do.

I'm running the following:

i5 3750K [Ivy Bridge] (overclocked to 4.7 GHZ)

GTX660 Ti FTW Signature 2

16GB Corsair Vengeance RAM

Samsung 840 250 GB SSD

ASUS Sabertooth Z77 Motherboard running the show

http://cpuboss.com/cpus/Intel-Core-i7-980X-vs-Intel-Core-i5-3570K

On paper your chip the 980X is multi-core devourer of worlds but in single core applications the 3750K runs faster. I'm not sure if L5 takes full advantage of multi-threading or not but it surely seems that you should be getting much more traction with your PC.

https://community.logos.com/discussion/comment/513356#Comment_513356

Thanks for posting the screencast. Do you actually end up picking a collection from the drop-down list frequently, or do you more typically pick a single Bible? I'm wondering if it would be useful to make individual Bibles available in the list before all the collections were loaded.

Most often I'm typing the name of a collection to search in and looking for a match of that to select (I have one called "Search Bibles" which includes my favorite Bibles plus a bunch of others that I like Bible searches to include. Occasionally I search in one Bible, but not very often. Perhaps if the text typed into the search box matches exactly an existing collection name, it could allow you to hit Enter right away to select that collection, and bypass the whole populating-the-listbox thing. That's the most common way I use that dropdown, and it's frustrating to have to wait for the population to occur when I already know exactly the full name of the collection I'm looking for.

and nearly 20 seconds subsequent times, on my super fast machine. ... And it should be nearly instantaneous on subsequent times.

I'm not able to reproduce this problem. I have 500+ collections and the drop-down opens in under a second for me the second time I open it. (It's only slow the first time.) But perhaps solving the initial delay will fix the subsequent delay too?

Would it help to do some profiling on my machine in an instrumented version of Logos, to find out where the bottleneck is? I'm guessing that a log file won't be very helpful to you here, but I could post that if you think it would help.

https://community.logos.com/discussion/comment/513494#Comment_513494

Rosie, I have a similar sized library to you (10,488), and a similar specification PC (i7-3550K, 16GB RAM, Samsung 840 Pro SSD). My dropdown menu, takes about three seconds on first load, after that it occurs too quickly to accurately measure.

I wonder if Resource Monitor (or the Performance tab of Task Manager if you're running Windows 8), might help to narrow down where the bottleneck is occurring.

https://community.logos.com/discussion/comment/513515#Comment_513515

Got it - restarted Logos on my machine, as you see did a Search - I timed with a stopwatch, 16.3 seconds. WEI of 7.7, Intel i7-3920XM @ 2.9 GHz, 512GB SSD, 16GB RAM, Windows 7 x64.

Here is a screencast showing the behavior:

https://dl.dropboxusercontent.com/u/56053396/dropdown.swf

https://community.logos.com/discussion/comment/513515#Comment_513515

I wonder if Resource Monitor (or the Performance tab of Task Manager if you're running Windows 8), might help to narrow down where the bottleneck is occurring.

This is the first time I've ever wished I had a second monitor, so I could record the screen of Resource Monitor running while I try out the task in Logos.

EDIT: OK, here's a capture of Resource Monitor side-by-side with Logos while I'm doing this.

http://www.screencast.com/t/NeVOZZ23OzQ7 (it took about 20 seconds)

I'm not sure how to tell what the problem is from this. I see the CPU usage is pegged at 100% (though I don't know what the green area vs. orange and blue lines in that chart mean).

I did have a few other apps running at the same time (which I always do). I could try rebooting and running only Logos, but once again as a power user with a power machine, that shouldn't be necessary. I'm used to multi-tasking like crazy on my machine, and none of my apps slow down on me just because I've got a dozen of them running at once (e.g., Outlook, Word, Excel, MS Money, Chrome, Evernote, my photo database software, and a couple of other small things).

https://community.logos.com/discussion/comment/513555#Comment_513555

This is the first time I've ever wished I had a second monitor, so I could record the screen of Resource Monitor running while I try out the task in Logos.

Here's my capture. You'll see that there's no disk activity at all, just a relatively small CPU spike.

https://community.logos.com/discussion/comment/513555#Comment_513555

I'm not sure how to tell what the problem is from this. I see the CPU usage is pegged at 100% (though I don't know what the green area vs. orange and blue lines in that chart mean).

It's the green line that matters, so there's not much CPU usage. That could be because this is a single-threaded option, so it's only using one core. Do you have 16 cores? The blue line is just the CPU frequency. The orange line is the process you're currently monitoring. What's potentially interesting is that the green line is much higher than the orange line (which suggests that something else is using the CPU in addition to Logos). But I'm not sure that makes that much difference. The most useful fact about your capture is that nothing unusual happens. There's no big disk or memory spike, for example.

https://community.logos.com/discussion/comment/513555#Comment_513555

On further research, I can see that your CPU does have twice as many cores as mine. That reduces single-threading performance, and this is a single-thread operation. If you have three times as many collections as me, and more of those collections contains Bibles, then that could also contribute to poor performance.

But for Bradley, I think the thing to concentrate on here is why your menu doesn't cache. Could you record a screencast of a first and second click on the menu so we can see if there's any improvement between the two clicks?

My second thought is whether there's a problem with the dropdown itself. Judging by the names of several of the collections that I can see in your capture, they shouldn't contain Bibles (and therefore shouldn't be in the menu). For example, Books by Regent Profs, or Apologetics. Could you check whether these collections do contain Bibles? If they don't, that points to a bug, that might possible be causing all this.

My third thought is that you have a collection called Books not in any collection. If that contains 300 collections all in the Exclude column, I wonder whether calculating that collection is just proving too much, particularly if many of your other collections are also dependent on one another.

https://community.logos.com/discussion/comment/513564#Comment_513564

Do you have 16 cores?

Nope, 6 cores. See my machine specs here. I've actually since replaced the SSD with a slightly larger one (256 GB) since the first one died, but everything else is the same.

Here's another screencast, after a fresh reboot, with no other apps running beyond Logos and Resource Monitor and Task Manager, except Camtasia Studio (to do the screen capture), and the tiny Deskpins to keep Task Manager on top of Resource Monitor.

http://www.screencast.com/t/ZoZUO3XFK (18.7 seconds this time)

So having tons of other apps running isn't making much of a difference. Something else is going on. I'm dying to find out what, and for Bradley and co. to be able to get to the bottom of it and fix it.

Here's the log file from this session, in case it reveals anything interesting:

7120.Logos.log

Randy W. Sims

https://community.logos.com/discussion/comment/513575#Comment_513575

You've probably already done this, but have you checked to make sure any AV or system utilities you may be running exclude your Logos directory and processes? When looking at the Processes tab in Task Manager, sorted by CPU and then again by Disk Usage, do any other processes jump to the top when you click the Bible menu?

https://community.logos.com/discussion/comment/513573#Comment_513573

On further research, I can see that your CPU does have twice as many cores as mine. That reduces single-threading performance, and this is a single-thread operation.

Wow, I never realized that. I just thought the more cores you had the better/faster, and that it didn't help single-threading operations at all, but didn't harm them. Why would it reduce performance for single-threaded operations? Isn't one core fully engaged in performing that operation, so it shouldn't be any worse than a single-core processor fully engaged in performing that operation.

But for Bradley, I think the thing to concentrate on here is why your menu doesn't cache. Could you record a screencast of a first and second click on the menu so we can see if there's any improvement between the two clicks?

OK, here it is.

http://www.screencast.com/t/EMacq1zM

Not much faster the second time: 19 sec vs. about 22 sec. the first time.

Judging by the names of several of the collections that I can see in your capture, they shouldn't contain Bibles (and therefore shouldn't be in the menu). For example, Books by Regent Profs, or Apologetics. Could you check whether these collections do contain Bibles? If they don't, that points to a bug, that might possible be causing all this.

Nope, all those collections really do have Bibles in them. Books by Regent Profs includes The Message, translated by Eugene Peterson who was a professor of mine at Regent. Apologetics includes The New Jerusalem Bible for some reason. I haven't finished that collection (that's why it's got "(in progress)" after its title). Currently my rule is just apologetic, defen, difficulties, evidences, skeptics, convinc and I haven't gotten around to refining it. The New Jerusalem Bible matches that because it has the word "difficulties" in its description.

My third thought is that you have a collection called Books not in any collection. If that contains 300 collections all in the Exclude column, I wonder whether calculating that collection is just proving too much, particularly if many of your other collections are also dependent on one another.

Hmm, now there's an interesting thought. Yes, a number of my collections do contain other collections, though most do not. I will try deleting my "Books not in any collection" collection and try the experiment again, and see if that makes any difference.

Here we go:

http://www.screencast.com/t/AJAd1hZy2d

Doesn't seem to make a huge difference. First dropdown: 22 sec; second: 19 sec.

And again, here is the log file from this session.

4505.Logos.log

https://community.logos.com/discussion/comment/513581#Comment_513581

You've probably already done this, but have you checked to make sure any AV or system utilities you may be running exclude your Logos directory and processes?

Just tried it again with AV disabled and it didn't make any difference.

When looking at the Processes tab in Task Manager, sorted by CPU and then again by Disk Usage, do any other processes jump to the top when you click the Bible menu?

Nope, Logos is at the top. The only other processes using non-zero CPU are Camtasia (the screen recorder) and Desktop Window Manager. And Logos has by far the most memory usage. The other processes don't change in their memory usage when I drop down the menu.

https://community.logos.com/discussion/comment/513586#Comment_513586

Wow, I never realized that. I just thought the more cores you had the better/faster, and that it didn't help single-threading operations at all, but didn't harm them. Why would it reduce performance for single-threaded operations? Isn't one core fully engaged in performing that operation, so it shouldn't be any worse than a single-core processor fully engaged in performing that operation.

If you have a 6-core processor that's capable of running 10,000 operations per second, it follows that each core can run at 1,667 operations per second. If I have an 4-core processor that has the same overall performance, each core can operate at 2,500 operations per second. Hence, on a single threaded task, my processor will be 30% faster as yours. (Of course, the maths doesn't work out anywhere near this simply as this, but the overall point is sound.)

If you check the link below, you'll see that our processors have very similar overall performance, but mine has noticeably better single-core performance, because the processing power is split over fewer cores: http://cpuboss.com/cpus/Intel-Core-i7-980X-vs-Intel-Core-i7-3770K

https://community.logos.com/discussion/comment/513604#Comment_513604

If you check the link below, you'll see that our processors have very similar overall performance, but mine has noticeably better single-core performance, because the processing power is split over fewer cores: http://cpuboss.com/cpus/Intel-Core-i7-980X-vs-Intel-Core-i7-3770K

Ha, and yours is only 1/3 the price. Goes to show you that throwing more money at a machine doesn't necessarily make it a better machine. I've had this machine for 2-1/2 years now, so maybe it's getting to be time to upgrade to a faster one. But still, it's blindingly fast for everything else I do. It's really a pity that it takes such precise choice of chips and things for one's machine in order to get decent performance in Logos.

https://community.logos.com/discussion/comment/513586#Comment_513586

And again, here is the log file from this session.

I'm not sure if it's going to make any difference, but one of your collections is very slow. It's the one with this syntax:

(type:commentary,monograph) title:(john, johannine, "fourth gospel") -title:(apocalypse, revelation, 1, 2, 3, II, III, letter, epistle, calvin, owen, bunyan)

There's a misplaced opening parenthesis at the beginning — it should be type:(commentary, monograph), but I suspect the problem is with the 1, 2, 3, II, III later in the string. You should replace that with "1 John", "2 John", "3 John", "II John", "III John", because it's matching too much at the moment, and therefore needing to write to a temporary file. That said, subject metadata is 1,000 times better than it used to be, so you can probably just re-create the collection with a simple type:(commentary,monograph) subject:"Bible.N.T.John".

In all you have 159 collection rules*, that take about 4 seconds to process. As that's approximately the time difference between your first click and second click, I'm going to suggest that Logos is caching the collection rules, but it's not caching which collections have Bibles in them (which seems contrary to what Bradley said was the case). By way of comparison, I have 144 rules, that take 3.3 seconds. Perhaps Bradley could clarify this, and look into what might cause Rosie's configuration to take 19 seconds to work out which collections contain Bibles.

* By this I mean that Logos has to process 159 rules in order to calculate your collections.

https://community.logos.com/discussion/comment/513620#Comment_513620

As a small note to the conversation, per my screen cast above 1st time populating it's 16 seconds, after that it is consistently 3 seconds. So it seems to be caching, something else must be going on.

Randy W. Sims

https://community.logos.com/discussion/comment/513620#Comment_513620

I'm going to suggest that Logos is caching the collection rules, but it's not caching which collections have Bibles in them (which seems contrary to what Bradley said was the case).

There might be a way to test that. The caching also seems to occur when you open the Library, activate the info pane, select a resource and scroll down to the collections section. Where it takes a while to populate. If I let that populate and then go to search and select the Bible drop down, it is instantaneous whereas if I go straight to search on startup and select it it takes around 7-8 secs (I have about 1/2 the resources, but I'm on a hdd). So it seems to be cached once, including which collections contain Bibles, anytime the UI needs to run the collections. ???

https://community.logos.com/discussion/comment/513622#Comment_513622

As a small note to the conversation, per my screen cast above 1st time populating it's 16 seconds, after that it is consistently 3 seconds. So it seems to be caching, something else must be going on.

Could you upload your logs? It would be interesting to see how long your collections take to calculate.

https://community.logos.com/discussion/comment/513620#Comment_513620

I'm not sure if it's going to make any difference, but one of your collections is very slow. It's the one with this syntax:

(type:commentary,monograph) title:(john, johannine, "fourth gospel") -title:(apocalypse, revelation, 1, 2, 3, II, III, letter, epistle, calvin, owen, bunyan)

There's a misplaced opening parenthesis at the beginning — it should be type:(commentary, monograph), but I suspect the problem is with the 1, 2, 3, II, III later in the string. You should replace that with "1 John", "2 John", "3 John", "II John", "III John", because it's matching too much at the moment, and therefore needing to write to a temporary file.

Thanks for catching that. I fixed it (both problems), but it didn't affect the performance any.

In all you have 159 collection rules*, that take about 4 seconds to process. As that's approximately the time difference between your first click and second click, I'm going to suggest that Logos is caching the collection rules

Huh? (the bold bit) I don't get that. My second click doesn't come until after the menu has fully populated and I've dismissed it. So my second click is about 23 seconds after my first click.

https://community.logos.com/discussion/comment/513627#Comment_513627

The caching also seems to occur when you open the Library, activate the info pane, select a resource and scroll down to the collections section.

Given that scenario, I would still suggest it means that Logos is caching the collection rules, but not caching which collections have Bibles in them. It's just that on your installation (and mine), working out which collections have Bibles is near instantaneous, whereas Rosie's installation is taking 19 seconds to work that out.

(The other alternative is that the problem is caused with the drawing of the menu, but Rosie's menu doesn't seem much longer than mine.)

https://community.logos.com/discussion/comment/513632#Comment_513632

Mark, I'm having a similar problems as Rosie. Will try back up collection rules and see how long it takes for the menu to finish loading.

https://community.logos.com/discussion/comment/513631#Comment_513631

In all you have 159 collection rules*, that take about 4 seconds to process. As that's approximately the time difference between your first click and second click, I'm going to suggest that Logos is caching the collection rules

Huh? (the bold bit) I don't get that. My second click doesn't come until after the menu has fully populated and I've dismissed it. So my second click is about 23 seconds after my first click.

Sorry. There are three tasks: (1) Calculate the collections rules, (2) Find out each collections have Bibles, (3) Draw the menu.

If we know that the first task takes about 4 seconds (which the logs say it does), and that it takes four seconds longer to generate the menu first time around, that suggests the only difference between the first time and subsequent times is that task (1) is cached. Equally it suggests that task (2) is not being cached.

So, in summary:

We know task (1) takes about 4 seconds.
We know task (3) is nearly instantaneous (because the dropdown on a basic search is near instantaneous for you).
We therefore know that task (2) is the one causing all the trouble — for you, but not for me.

If Logos are to fix the problem they will need to work out (a) Why isn't task (2) cached as Bradley suggested it was; and (b) why does it take so long anyway or some machines.

Out of interest, how long does the dropdown on a morph search take?

https://community.logos.com/discussion/comment/513628#Comment_513628

Could you upload your logs? It would be interesting to see how long your collections take to calculate.

Here is my log file - I started fresh, opened the drop down three times. I did not have the stop watch, I woukd say first time was well over 20 seconds, second time 12 seconds, third time 3 seconds.

4760.Logos.log

https://community.logos.com/discussion/comment/513633#Comment_513633

Mark, I'm having a similar problems as Rosie. Will try back up collection rules and see how long it takes for the menu to finish loading.

As a further thought, could tags be causing the problem? Could everyone posting let us know:

The time taken to display the dropdown (not on the first click).
Roughly how many resources, collections, custom series, and tags you have.

My menu speed is near instantaneous. I have approx 10,500 resources, 150 collections, 3 custom series, and 14 tags.

https://community.logos.com/discussion/comment/513639#Comment_513639

Here is my log file - I started fresh, opened the drop down three times. I did not have the stop watch, I woukd say first time was well over 20 seconds, second time 12 seconds, third time 3 seconds.

Thanks. I think that suggests yours is working OK. The slow first time was caused mainly by Logos updating community metadata whilst you were waiting for the dropdown menu. Often the new metadata caused it to start recalculating again.

https://community.logos.com/discussion/comment/513641#Comment_513641

As a further thought, could tags be causing the problem? Could everyone posting let us know:

The time taken to display the dropdown (not on the first click).

19 sec.

Roughly how many resources, collections, custom series, and tags you have.

11,000 resources
280 collections
maybe a max of 3 custom series, but I can't remember (how can I figure this out?)
387 tags [could this be the problem? I'm a heavy user of tags, for all kinds of purposes]

https://community.logos.com/discussion/comment/513646#Comment_513646

387 tags [could this be the problem? I'm a heavy user of tags, for all kinds of purposes]

Let's test the hypothesis: Users with slow dropdowns have lots of tags, users with fast dropdowns have few tags?

So far (just looking at me and you), the hypothesis is true. But we need more data!

https://community.logos.com/discussion/comment/513651#Comment_513651

Deleted a number of collections, now my dropdown is instant. Will add them one by one, and see if I can narrow it down.

https://community.logos.com/discussion/comment/513654#Comment_513654

After a cold booth, took approximately 9 seconds. One of the collections that may be the culprit is the collections for the entire library. The second time that I tried the menu, it is instant.

https://community.logos.com/discussion/comment/513659#Comment_513659

Restarted the software and the menu took four seconds to populate.

https://community.logos.com/discussion/comment/513654#Comment_513654

Deleted a number of collections, now my dropdown is instant. Will add them one by one, and see if I can narrow it down.

One of the collections that may be the culprit is the collections for the entire library. The second time that I tried the menu, it is instant.

I had one collection for the Entire Library which I don't need, so I deleted it. I also deleted a couple more that were nearly the entire library (rating:>=0 minus some type or some specific resources).

No change in the performance. Sigh.

https://community.logos.com/discussion/comment/513665#Comment_513665

Another cold booth. The menu takes appx. nine seconds the first time, and instant the second time, even after closing the search panel.

Restarted the software, and ran the search again, was 3-4 seconds.