System Resource Hog?

I started with Logos 6 and I realized that the program is somewhat of a resource hog. So I thought the free upgrade to 7 would fix that. Still a system resource hog. Now in 8, it is still just as much of a memory hog as it has been before. I am not trying to be critical, but last night I rendered a 3 minute video in after effects and it used half as much of my system as Logos. Logos indexing slows my system way down while I can do other things in the back ground while After Effects renders. I realize that After Effects uses my video card to do a lot of the hard work, but is there some way to index the library more efficiently? I love the program, but it really doesn't like you to multi task in other apps.

Find more posts tagged with

Desktop App

Comments

Mike Binks

Joshua

Welcome to the forums.

A quick review of the posts here will convince you that your experience is atypical with many reporting significant speed improvements.

Most are finding indexing - while still processor intensive is substantially faster now.

One of the things that does seem to cause significant slowdowns of systems is having a large number of collections. Collections have to be rebuilt every time the program starts up and some users have benefitted from a clear out.

Another common problem is an over-full hard drive.

If this is not your problem you might like to submit some logs (see my signature line) and one of the gurus will have a look to see where the hold up is occurring. Please use the paper clip icon in the tool bar here to attach the zipped logs to a post in this thread and confirm your OS and Logos version number. I am assuming that your post contains a couple of typos and you have upgraded to Logos 8?

Mark Smith

Joshua, FL introduced some efficiencies in indexing some time ago. However to benefit fully from them you have to reindex your Library. Type Rebuild Index into your command or Go bar and hit enter.

Joshua Davis

https://community.logos.com/discussion/comment/1009994#Comment_1009994

Thanks for the reply. I basically refreshed everything and let it re-index everything. I don't have the largest library, I have what I need. I did notice that once indexing is done, it seems to be snappier than in previous versions. When I did a fresh install, I did notice indexing didn't take as long.

I'll keep an eye on things and if I keep having problems, I'll submit an official support tickets. Thanks again.

Gregory Lawhorn

https://community.logos.com/discussion/comment/1009977#Comment_1009977

One of the things that does seem to cause significant slowdowns of systems is having a large number of collections. Collections have to be rebuilt every time the program starts up and some users have benefitted from a clear out.

Yesterday I went through my Collections, and was surprised to find that I had several dozen. I removed the majority, restarted Logos, and immediately noticed a speed difference.

Rick Ausdahl

https://community.logos.com/discussion/comment/1009977#Comment_1009977

One of the things that does seem to cause significant slowdowns of systems is having a large number of collections. Collections have to be rebuilt every time the program starts up and some users have benefitted from a clear out.

I'm not questioning the fact that they are rebuilt every time the program starts, but I can't help but question what that really means (i.e. what it entails) and why it has to be that way. Over the years, I've repeatedly heard that the ability to create collections is one of the great features in Logos. What good is it if it has such a negative affect on performance?

Bradley Grainger (Logos)

https://community.logos.com/discussion/comment/1010161#Comment_1010161

What good is it if it has such a negative affect on performance?

Most collections are fine, and very little is gained by taking the time to prune them back.

We originally envisioned that users might create a few dozen simple automatic collections, such as lang:Greek type:Bible or type:Commentary title:Genesis.

However, we found out that users had much grander visions and started created collections like these ones: https://community.logos.com/forums/p/88829/978914.aspx#978914

(It's somewhat obvious that these were never anticipated when you look at the single-line editing UI where you enter these rules; how are you even supposed to edit them easily?)

Some of these rules take multiple seconds to evaluate, and some users have dozens or hundreds of these rules. This is what can slow down the system.

As we became aware of this problem, we started investigating ways to mitigate it. In some cases, such as "* -mytag:*", we were able to ship an update to Logos that made those queries evaluate hundreds of times faster. But for the Author/Denomination/Tradition/Commentary collections, we were unable to do this; the next best approach we were able to develop was new syntax that was both more precise and much more efficient. You can see some examples here: https://community.logos.com/forums/p/88829/624737.aspx#624737

Mark rewrote his collections to use the new syntax, which addresses most of the performance problems. You shouldn't see any issues from having a dozen or so collections in that format.

But if you've got hundreds of "denomination" collections using the old syntax, especially if you use them very infrequently, you may see substantial performance improvements in Logos by deleting them from your application.

Mark Smith

https://community.logos.com/discussion/comment/1010186#Comment_1010186

But if you've got hundreds of "denomination" collections using the old syntax,

I have two of these and yesterday updated them to the correct syntax. I can say that it is quite a job to do so, as one needs to be precise in specifying the search terms. Mark B. had to spend a lot of time on some of those larger collection rules.

Rick Ausdahl

https://community.logos.com/discussion/comment/1010186#Comment_1010186

What good is it if it has such a negative affect on performance?

Most collections are fine, and very little is gained by taking the time to prune them back.

We originally envisioned that users might create a few dozen simple automatic collections, such as lang:Greek type:Bible or type:Commentary title:Genesis.

However, we found out that users had much grander visions and started created collections like these ones: https://community.logos.com/forums/p/88829/978914.aspx#978914

(It's somewhat obvious that these were never anticipated when you look at the single-line editing UI where you enter these rules; how are you even supposed to edit them easily?)

Some of these rules take multiple seconds to evaluate, and some users have dozens or hundreds of these rules. This is what can slow down the system.

As we became aware of this problem, we started investigating ways to mitigate it. In some cases, such as "* -mytag:*", we were able to ship an update to Logos that made those queries evaluate hundreds of times faster. But for the Author/Denomination/Tradition/Commentary collections, we were unable to do this; the next best approach we were able to develop was new syntax that was both more precise and much more efficient. You can see some examples here: https://community.logos.com/forums/p/88829/624737.aspx#624737

Mark rewrote his collections to use the new syntax, which addresses most of the performance problems. You shouldn't see any issues from having a dozen or so collections in that format.

But if you've got hundreds of "denomination" collections using the old syntax, especially if you use them very infrequently, you may see substantial performance improvements in Logos by deleting them from your application.

Bradley,

Thanks for the very quick reply and I'll just say, "Point Taken". [:)] I couldn't help but laugh a bit as I browsed through some of the collection rules developed by those users who had a "grander vision" than what Faithlife originally planned or could have likely anticipated.

If it's examples like those that cause the slow-down concerns, I don't think it's likely that I'll ever have much to worry about based on the rules required for my "not-quite-so-grand" collection needs.

There is one part of my inquiry though that I don't think was addressed and I'm still a little curious about--that's "why" the collection rules have to be rebuilt each time Logos is started, as opposed to just saving and pulling the previously built rules in unless they've been changed--something that could be evaluated quickly by setting a flag if/when a collection rule has been changed. But ...I won't be upset if you'd rather not go into that.

Thanks again for the explanation!

Bootjack

https://community.logos.com/discussion/comment/1010205#Comment_1010205

Sorry people but I have to ask, what is collections? And what is clearing out collections and how is it done? I've not heard or read the term before until now, although to be fair, I don't frequent the forums that much.

Mark Smith

https://community.logos.com/discussion/comment/1010225#Comment_1010225

The collection tool can be accessed from the Tools menu.

Collections are ways to organize resources that are in your Library. In some ways they are like arranging books on a shelf. They let you put books together of a similar type, on a similar topic, or by the same or a group of authors. You can use collections to help you remember what's in your Library, and they can be used to limit the range of searches or can be part of one of your guides, like a Passage Guide, Topic Guide, or Sermon Starter Guide.

I have collections by author, subject, topic, type of resource, and series. Some examples are: English Bibles, Bible Dictionaries, Theological Dictionaries, Expository Commentaries, Maps, Greek Testaments, Greek Lexicons, and Charles Stanley Collection. I find they let me locate what I'm looking for more easily as I browse my Library, and let me find what I want in searches and in guides.

Back in L4 or L5, I believe, FL developed the tools to give us the ability to form collections using Library selection criteria so that any time after we build the collection and then add a new book to our Library that matches a Collection's rule it is automatically added to the Collection, saving us time. This is called a dynamic collection.

FL has a description and some directions here. The wiki has more information here.

Bootjack

https://community.logos.com/discussion/comment/1010236#Comment_1010236

Using Logos for how many years now and I was not aware of that, so I guess I don't have any to remove. Thank you Mark for the clear explanation. Your help is always appreciated.

Mark Barnes

https://community.logos.com/discussion/comment/1010205#Comment_1010205

There is one part of my inquiry though that I don't think was addressed and I'm still a little curious about--that's "why" the collection rules have to be rebuilt each time Logos is started, as opposed to just saving and pulling the previously built rules in unless they've been changed--something that could be evaluated quickly by setting a flag if/when a collection rule has been changed. But ...I won't be upset if you'd rather not go into that.

It's very likely because the rules are cached in RAM, for maximum speed benefit. By definition RAM is not persistent, so they therefore have to be recalculated every time you restart Logos.

If they were cached on disk they'd be multiple times slower. You could (in theory) cache them on disk, and then read the disk file into RAM. That would slow down the writing process but may speed up the reading process. But I imagine that would be a lot of extra code for uncertain benefits. (It would even up slower in some (many?) scenarios.)

For people like me who use Logos every day, there's no reason to shut the app. Just keep it open. It's very stable and doesn't tend to be one of those apps that has to be constantly restarted to stop memory use creeping up constantly.

Rick Ausdahl

https://community.logos.com/discussion/comment/1010409#Comment_1010409

There is one part of my inquiry though that I don't think was addressed and I'm still a little curious about--that's "why" the collection rules have to be rebuilt each time Logos is started, as opposed to just saving and pulling the previously built rules in unless they've been changed--something that could be evaluated quickly by setting a flag if/when a collection rule has been changed. But ...I won't be upset if you'd rather not go into that.

It's very likely because the rules are cached in RAM, for maximum speed benefit. By definition RAM is not persistent, so they therefore have to be recalculated every time you restart Logos.

If they were cached on disk they'd be multiple times slower. You could (in theory) cache them on disk, and then read the disk file into RAM. That would slow down the writing process but may speed up the reading process. But I imagine that would be a lot of extra code for uncertain benefits. (It would even up slower in some (many?) scenarios.)

For people like me who use Logos every day, there's no reason to shut the app. Just keep it open. It's very stable and doesn't tend to be one of those apps that has to be constantly restarted to stop memory use creeping up constantly.

Thank you, Mark! FWIW, I'm not pushing for changes in how it's done. I don't currently have enough skin in the game regarding collections to qualify as a real stakeholder on the issue, although I expect to be more so down the road. I was mainly curious as to why this feature that is so valued by many users, comes up as often as it does as a "gottcha" regarding Logos performance.

My impression is the rules-building primarily affects start-up performance and it does so because Logos rebuilds ALL the collection rules at once upon startup. I wonder if that issue could be resolved by keeping all the collection rules cached on disk (please hear me out) and only reading the rules into RAM one collection at a time if/when the collection is called for by the user. That could substantially eliminate the slow-down during start-up and eliminate it all-together if the layout to which Logos opens doesn't call for a collection. And I'm guessing it would only have a minimal impact on performance (maybe not even noticeable) the first time a specific collection is called for after Logos is started since Logos is only having to build the rules for that one collection. Even if reading the rules when cached on a slow mechanical disc, pulling in the rules for a single collection would probably be pretty fast, and all the faster when pulled from a SSD.

I'm just thinking out loud. I'm not asking anyone to respond. [:^)]

Mike Binks

https://community.logos.com/discussion/comment/1010469#Comment_1010469

I'm just thinking out loud. I'm not asking anyone to respond.

Here then is a voluntary response 😊. I think you are right!

John Fidel

https://community.logos.com/discussion/comment/1010469#Comment_1010469

I am just offering this as an alternate to using complex formulas in collections. What I do for example would be to take one of the commentary formulas such as those that Mark has put together, copy and paste it into the search box in my Library. This now shows all the commentaries that should be in that collection. I now select all and tag the resources with a name such as Technical.

Tags can be used in many situations the same way as collections. However, if I want to create a collection.I simply use mytag:Technical and I have the collection. Or if I only want my favorites of those I can easily add rating:>3 to the formula.

Downside is when I add resources, I need to tag them to get them into the correct collection or common tag where a collection formula, if properly written will include it automatically. I do not add so many resources that maintaining tags is difficult.

Just an alternate method.

Mark Barnes

https://community.logos.com/discussion/comment/1010469#Comment_1010469

My impression is the rules-building primarily affects start-up performance and it does so because Logos rebuilds ALL the collection rules at once upon startup. I wonder if that issue could be resolved by keeping all the collection rules cached on disk (please hear me out) and only reading the rules into RAM one collection at a time if/when the collection is called for by the user. That could substantially eliminate the slow-down during start-up and eliminate it all-together if the layout to which Logos opens doesn't call for a collection. And I'm guessing it would only have a minimal impact on performance (maybe not even noticeable) the first time a specific collection is called for after Logos is started since Logos is only having to build the rules for that one collection. Even if reading the rules when cached on a slow mechanical disc, pulling in the rules for a single collection would probably be pretty fast, and all the faster when pulled from a SSD.

There are many places in Logos that require ALL the collections, not just one. The new facets in the Library is the most obvious example. The parallel resource menu is another. But even the dropdown menu that allows you to choose a Bible in a Bible search only shows collections that actually contain a Bible. That of course is only possible if Logos already knows what's in each collection — and there are plenty of similar examples.

Mark

https://community.logos.com/discussion/comment/1010485#Comment_1010485

I am just offering this as an alternate to using complex formulas in collections.

Thanks John for this suggestion.

Mark Barnes

https://community.logos.com/discussion/comment/1010485#Comment_1010485

Just an alternate method.

This used to be a good way of improving startup performance at the expense of extra time taken with the tagging (which itself can take a long time). Personally, with the new syntax I don't think it's necessary any more.

Rick Ausdahl

https://community.logos.com/discussion/comment/1010489#Comment_1010489

My impression is the rules-building primarily affects start-up performance and it does so because Logos rebuilds ALL the collection rules at once upon startup. I wonder if that issue could be resolved by keeping all the collection rules cached on disk (please hear me out) and only reading the rules into RAM one collection at a time if/when the collection is called for by the user. That could substantially eliminate the slow-down during start-up and eliminate it all-together if the layout to which Logos opens doesn't call for a collection. And I'm guessing it would only have a minimal impact on performance (maybe not even noticeable) the first time a specific collection is called for after Logos is started since Logos is only having to build the rules for that one collection. Even if reading the rules when cached on a slow mechanical disc, pulling in the rules for a single collection would probably be pretty fast, and all the faster when pulled from a SSD.

There are many places in Logos that require ALL the collections, not just one. The new facets in the Library is the most obvious example. The parallel resource menu is another. But even the dropdown menu that allows you to choose a Bible in a Bible search only shows collections that actually contain a Bible. That of course is only possible if Logos already knows what's in each collection — and there are plenty of similar examples.

Thanks once again, Mark. That pretty much puts a wrap on it.

Me thinks it's time to zip my lip on the subject [:#] and focus on enjoying Logos 8. [8-|]

John Fidel

https://community.logos.com/discussion/comment/1010492#Comment_1010492

Just an alternate method.

This used to be a good way of improving startup performance at the expense of extra time taken with the tagging (which itself can take a long time). Personally, with the new syntax I don't think it's necessary any more.

Glad to hear, however, I am all in now.