Increased delay in parallel resource drop down display time.

Back on January 29th I commented in the following thread that the drop down for parallel commentaries took about 5 seconds before the list was presented.

http://community.logos.com/forums/t/10731.aspx

I just did the same test, and it now takes over 15 seconds for the list to be populated the first time. Can some effort be made to improve the performance here. It seems that something has changed and made an already unacceptable delay more than 3 times worse.

Is there anyway this could be precomputed using a background thread when the commentary/bible/book changes to a new verse being displayed?

Thanks,

Clinton

PS. Running 4.0D RC1, my computer is the same as it was in January with the exception of a faster hard disk now.

Find more posts tagged with

Comments

JimTowler

I noticed this too at one point. Mine went from about 2-4 seconds to 3x as long.

I had a number of Collections where I had ticked "Show in Parallel Resources".

Based on my system, it seems the application spends way too long remaking the lists over and over. It seems it should "make" them and save it somehow, unless your resources have updated.

For now, untick some of your collections and see if it makes any difference, and report back here. If what I've just said does not explain it, thats important to know. If thats it, then it will be an important aspect for Logos to review the performance of that specific portion of the code logic.

I hope this is more helpful than confusing.

Clinton Thomas

https://community.logos.com/discussion/comment/141967#Comment_141967

For now, untick some of your collections and see if it makes any difference, and report back here.

I only have one small collection and having it show/not show in parallels does not significantly change the times. I did this test before I started this update thread. Also, the test I did in January and the test now were with the same collection having the same books in it. The program has become less efficient.

It is important to note that I think that all drop downs of this sort should show in less than one second.

Note that the list of resources may update every time you change a verse so the "make" them and save it approach will not work. This is because a new verse might be in a different commentary volume which means that even though your resources on your computer have not updated, the list of them that are applicable to the current verse has, BUT the list is not so dynamic that a sub one second response time is not achievable. Again, the list creation needs to be

optimized for performance (the code is less efficient now than before)
precomputed in a background thread.

Logos had this problem with Libronix where the parallel dropdown was too slow and users (at least this one did) complained about it there and they fixed it, they need to do it again!

JimTowler

https://community.logos.com/discussion/comment/141971#Comment_141971

Clinton,

Your points noted. I agree, in expecting most menus to react and display within a second. The exception is where is a context-sensitive search, in which case, a lot of work has to be done to get the result.

In the case of a bible verse, which is going to be a very common, it seems Logos4 should maintain internal lists or bitmaps of all possible hits. Given its only a few seconds, rather than minutes, something like this is already going on.

Given my Logos4 install already uses over 10GB of disk, I would gladly give up a little more for pre-computed hit-lists, and other related kinds of things, so that things go faster. If need be, the application could be designed to do stuff the "hard way" if required, or use the pre-computed thing(s) if its present and current. In that kind of case, users could elect to have, or not have, something pre-built if it was very large.

Imagine: "Do you want to allow Logos4 to build a Parallel Resources Level-2 Database Level? (It is estimated that this will consume 3.2 GB of disk storage, and change lookup times from 8-12 seconds to under 0.25 in general.)"

(If something is small, it should just do it and never ask of course.) I would let mine use the extra storage.

Trey Selman

I have also noticed the same delay. Mine is currently at about 6 seconds to populate.

It would be nice if it could populate a little faster. It would increase the enjoyment of the study process.

It's still a lot faster than opening up 5-10 books to the same location so that 6 seconds doesn't seem so long when I keep that in mind!

Melissa Snyder

Development is working on optimizing the parallel resource sets. I'll add this thread to the case. Thanks.

Stein Dahl

I just did the same test, and it now takes over 15 seconds for the list to be populated the first time. Can some effort be made to improve the performance here. It seems that something has changed and made an already unacceptable delay more than 3 times worse.

I also have noticed that the parallel resources menu takes way too long to populate. The program seems to have to redraw the graphics everytime you use a drop-down menu. And the incredible amount of pop-ups that occur when you use the Library is very annoying.

So, I suggested, at one point, that Logos should add an option to turn off graphics in any drop-down menu - including the Library.

Now - mind you - this should be an OPTION - that users can decide to use or not - an option to turn off all graphics in only the drop-down menus.

Turning off graphics in drop-down menus would speed up the menus considerably. Besides, why do we have to have all those graphics in the drop-down menus? I can see having graphics in the main parts of the program, but drop-down menus don't need all those pictures.

IMHO a list of books would suffice in any drop-down menu.

Clinton Thomas

https://community.logos.com/discussion/comment/142034#Comment_142034

It's still a lot faster than opening up 5-10 books to the same location so that 6 seconds doesn't seem so long when I keep that in mind!

Hi Trey,

This is an apples and oranges comparison. The correct comparison is how fast do software programs in general populate drop down menus. How fast do other bible software programs populate their drop down menus.

I would suspect the numbers would be

1,000,0000,000 programs approximately 1 second

1 program (Logos) approximately lots of seconds (6-15 times slower)

Regards,

Clinton

PS I might be overstating the number a little.

Clinton Thomas

https://community.logos.com/discussion/comment/141985#Comment_141985

The exception is where is a context-sensitive search, in which case, a lot of work has to be done to get the result.

Hi Jim,

I agree with this.

How about this, if Logos can make it so I can search my entire library of 1000's of resources with thousands of hits in a second, surely presenting a list of 10 commentaries should not take 10 to 15 times as long.

Regards,

Clinton

PS I know...stop calling me Shirley

JimTowler

https://community.logos.com/discussion/comment/142085#Comment_142085

Well, in this case, I expect we can trust what Melissa says above, and that the dev team is working on this performance issue.

In the past, computers had little memory, disk and power, so the only way was the hard way - or something really smart and/or tricky.

Now, with memory and disk to spare, I hope they can find ways to cache / background pre-compute etc, so this menu can be sub-second delay.

steve clark

https://community.logos.com/discussion/comment/142083#Comment_142083

1,000,0000,000 programs approximately 1 second

Please forgive me in advance [:D]

Your second cluster of zero's has 4 in it.

Your computer's CPU runs in gigahertz (clocking speed). Your number represents 1 gig (1e9; ignoring the extra zero). Your CPU runs at maybe 2 to 3 GHz. So your CPU can perform one operation (loading a register for example) in several of these clock cycles. Thus for your computer to paint a drop-down menu it would require thousands of computer cycles to perform this (conservatively speaking). So a more reasonable assumption would be that perhaps a drop-down menu could be update in 1000th of a second. Even if it updated in hundredths of a second it would be unnoticeable to the human eye as it reacts much slower.

again forgive me, i do realize your point. But under the hood of L4 for the parallel resource feature, it is searching every parallel resource for your specific reference prior to populating the drop down list.