Any foreseeable speed updates to L4 Mac

Running L4 Alpha 23 for Mac on MacBook Pro, OS X 10.6.4, 2.53 Intel Core Duo, 4G 1067MHzDDR3

I get that it's still in Alpha, but the tutorial videos and the memories of the Demo done at the conference where I purchased the software have left me wanting (I know the Demos and Tutorials are PC)

Are there any settings that may help? Is there a way for me to easily limit the resources being searched and thereby cut down on search time? Would this help the scrolling and linking?

Don't regret the purchase. I'm just a little teased with the potential I see and am looking forward to full usability.

Thanks for any suggestions (in "for idiots" lingo please).

Find more posts tagged with

Comments

Thomas Ball

Erik:

Where precisely are you noticing speed issues. What are you doing when you notice this? Please be detailed.

LeastLikely

https://community.logos.com/discussion/comment/144684#Comment_144684

Example: in a layout with a Bible Panel and commentary panel, every time I change the text in the bible panel, the commentaries take up to 20 seconds to follow. Even when loading a new layout, it won't pop up for about 10 seconds, then I have to wait for all of the commentaries, etc. to load for another 10-15 seconds. With the commentaries in the passage guide taking so long, I'm not allowed to scroll through linked texts in bible panel because the commentaries take forever to catch up (often ending in software crash). Is there a way to limit the resources in the passage guide initially to make their linking faster? I've only been using the software a couple of weeks. Please excuse any ignorance.

Mike Binks

https://community.logos.com/discussion/comment/144700#Comment_144700

Greetings Erik

This isn't a solution from a software point of view but more a work flow observation.

Generally when I am looking at a text - usually for a sermon - I don't really want the passage guide linked to either the Bible Text or the actual commentary that I am using. So I don't link it - that way it stays with the resources showing that apply to my main area of study.

I will have the Bible and the commentary that I happen to be using linked (you can easily go back to the main passage using the arrows on the top of the pane). I will then have a second copy of the bible open to send hyperlinks to, so that references can be seen in context.

Using the program this way it is very responsive and quick to react.

Linking the passage guide to a scrolling text will always require a huge amount of processing power and is unlikely ever to be completely smooth. I also find linking it this way is counter productive when it comes to actual work with the programme.

I hope the above makes sense - come back if not and I will try and explain more clearly.

tootle pip

Mike

Keep Smiling 4 Jesus :)

https://community.logos.com/discussion/comment/144852#Comment_144852

Agree with Mike: Passage Guide + Link Set => Sluggish

Logos Blog has Passage Guide tips => http://blog.logos.com/mt-cgi/mt-search.cgi?IncludeBlogs=1&tag=Passage%20Guide&limit=20

[I] Tools Menu => Passage Explorer (scrolls nicely with link sets):

By the way, Learning Greek DVD provided motivation for layout of Bible texts, lexicon, some commentaries, and Explorer - fills 27" iMac screen.

Keep Smiling [:)]

Martin Diers

I find Logos 4 Mac unusably slow on my Core2Duo 2.8 8Gb if I have several linked resources open, and it is especially bad if the passage explorer is one of them.

Just to keep myself sane, I stopped using the Explorers, and I have a number of smaller layouts targeting very specific purposes: NT Exegesis, OT Exegesis, Sermon work, etc., It's still slow, but tolerable.

The way these porting projects tend to go is that first they work on stability and features, then they work on optimization. So I am still very hopeful that once the Alpha series is feature complete, and the bulk of the crasher bugs are squashed, they will move on to performance work in the Beta series. There is nothing intrinsically slow about text lookup and display, even of a large number of resources. It will just take some work to get there.

Large computers make us sloppy by default - and this is not always a bad thing. It allows us to focus on the end goal without having to fight system resource issues. Code to your features first. Then optimize. The result is a much broader project in a shorter period of time than would otherwise be possible. Back in the day, resource contention was a constant problem, we were forced to code light and small, which while effective, also meant that the feature richness of the end-product was drastically curtailed. I take my hat off to guys like Larry Pierce who coded full index Bible Text search engines that could run like lightning on machines where memory was measured in Kbs not Gbs, and speed in Mhz not Ghz. We owe these pioneers a great debt of gratitude.