Libronix Bible Speed search is embarrassingly slow

RichardHendricks:

While this video covers the mac, I can tell you that the Windows version is just about as slow.

We know the Windows version is slow compared to BibleWorks, etc and trust this will be redressed in v4! I'm surprised the mac version appears to be just as slow (more later when I see the video).

Later:

I'm shocked - what do Mac users think?

 

JackCaviness:

The only practical value of such a demonstration is bragging rights. If you want to make a comparison of something useful, try using the various packages for serious Bible study.

The point is why is a native Mac implementation so slow? It seemed that my v3 search in Windows 7 was slightly faster and there have been claims (Logos) for v4 speed that put it in the same ball park as BW etc. 

BTW I do agree about speed of single word searches vs more complex word relationships (e.g. x before y), but there is a correlation wrt speed.

RichardHendricks:

Check out this video at http://homepage.mac.com/rmansfield/thislamp/files/20090731_libronix_vs_Accordance_1.html. While this video covers the mac, I can tell you that the Windows version is just about as slow. In the comments, I see that the same search in BibleWorks 8 returned the results in 0.36 secs. I confirmed that WordSearch 8 returns the results in less than a second.

So this is LDLS running on a Mac - another reason to not get a Mac. Of course, that's what he's comparing: another Mac Bible program with LDLS.

I notice a couple of things:

first it looks weird: there's no 'workspace' background and he has no Bible open. (I've only used Speed Search with a Bible open - since it's default is to search the Bible in the active pane.) So I'm not sure that it's a handicap, as he suggests, to have the material open in another part of the other program.

I also notice Speed Search is much, much slower on his machine than on mine. I got the list fully populated (well 1st 1000 results) in about 3 seconds with the NIV, and about 13 seconds for the NASB.

Regular search was also noticeably longer on his machine than mine. And once again the NASB took much longer to finish displaying the verse text (35 seconds) compared to the NIV (7 seconds).

This makes me wonder if the Accordance NASB is as fully coded as the LDLS NASB. If not, he is comparing apples with oranges (if you'll excuse the pun). Remember that the LDLS version of the NASB has all the Hebrew, Aramaic and Greek lemmas associated with the English words. This means that LDLS has to find the verse (which it does almost instantly), and then choose to display English data only. This is going to take noticeably longer in the NASB than searching an English only version -- and my search results show that searching the NASB takes about 4 or 5 times longer than searching the NIV. --At least play fair--

Third we have no way of knowing what his configuration is, and how (de)fragged his LDLS version of the NASB is. He obviously has a lot of stuff on his system and LDLS seems to be a later addition (increasing the opportunity for file fragmentation).

But it's no surprise to us that LDLS is slow doing searches. That's been talked about for years.

Bob promises search results will display much more quickly in version 4. (Though it will probably take a while to port v4 to the Mac.)

JackCaviness:

Dave Hooton:

JackCaviness:

The only practical value of such a demonstration is bragging rights. If you want to make a comparison of something useful, try using the various packages for serious Bible study.

The point is why is a native Mac implementation so slow? It seemed that my v3 search in Windows 7 was slightly faster and there have been claims (Logos) for v4 speed that put it in the same ball park as BW etc. 

BTW I do agree about speed of single word searches vs more complex word relationships (e.g. x before y), but there is a correlation wrt speed.

Dave

My point is that we become so enamored with the speed of certain functions that we lose sight of the overall usefulness of various applications. Logos Mac has a lot of other problems that are far more serious than the speed of a search that has no real value other than to see how fast you can display a long list of verses. This list has no other practical value.

Jack

I do not think it is fair to reduce the issue to a matter of vanity

I only use Bibleworks to do my Bible searches because I often need to find where a specific word or phrase is used in the Bible or in specific books.

with Bibleworks I can display the results in the entire bible and quickly move from the  occurences in one book to those in another. repeat such searches a number of time and speed makes a world of difference, especially when you need to tweak the terms in your search and repeat.

the issue is not just how fast the results are displayed, it is also about how fast you can browse through the results

Logos clearly sees that as a problem since they are seeking to address it in version 4

Alain

Here's the comment I posted on that video:

Ouch! We're going to have to work on that. 

Every product is a pile of compromises. Some products are almost entirely about searching, and assume that a text search of a single resource is the primary way people will interact with the material. So they're optimized for that.

Logos product is designed with the assumption that using a large library of resources is the primary interaction. So we put the Passage Guide front and center, not single book searching. (You're going to do a side-by-side comparison of our Guides to the guides in other products, too, right?)

In order to give the Passage Guide and other tools more flexibility in display, we used HTML for the interface for all our reports. On Windows it's IE, on Mac it's WebKit. 

The search is pretty fast -- the whole search is done as soon as the first result appears on the screen. The delay comes from A) loading the preview text and B) adding HTML to the web page that's hosted in IE or WebKit.

HTML is a complicated format to parse, and HTML renderers are designed to take a whole page and process it all at once. They aren't as efficient when you're inserting new HTML over and over, which we're doing as we throw the previews in one at at time.

On Windows, where IE has been designed to be a reusable component for a long time, the same speed search fills the screen in less than a second. But our port of this HTML based display architecture to the Mac clearly doesn't play to the Mac's strengths.

I'm not making excuses; I'm just providing an explanation. The fault is still ours -- we chose to use HTML, we chose to port the architecture of the Windows app to the Mac, we released the product, etc.

The feedback from most users has been great, though, and we consider Logos for Mac to be a success -- because most (not all) of the people using it are doing so to take advantage of the nearly 10,000 titles available for it and to use the automated research guides.

The users who are most concerned with repeated searches of a smaller number of books will surely find other products to be more useful.

The good news is that we're throwing away this architecture, which we first designed (for Windows) in 1998. It was cool and innovative then, and saved an enormous amount of work, allowing us to do more interesting things. But we have definitely gone beyond its usefulness.

The next version of Logos -- on both Windows and Mac -- is being built from the ground up with a new, modern codebase. There's no HTML, and we're using platform specific display technologies to remove the bottlenecks.

Comparison videos like this are great, and help developers in particular see what areas need the most attention. I just hope you'll come and revisit them with the future release, too!

-- Bob (with Logos)

Dave Hooton:

Bob Pritchett:

The next version of Logos -- on both Windows and Mac -- is being built from the ground up with a new, modern codebase. There's no HTML, and we're using platform specific display technologies to remove the bottlenecks.

The biggest sigh of relief should come from Mac users!

Dave

May biggest sigh arises from the fact that the next version of Logos Mac is being built in parallel with Logos Windows (at least I think Bob said that).

Thank you Bob for that insight. As usual, your posts are most informative.

Jack

I am with you Donovan. Regarding your points. 1. Yes, mine launches in two or three bounces as well.. something is wrong on his Mac I suspect. 2. Amen to that 3. My point exactly, even if the list is filling in below... who cares? I can't read that fast anyway :-) 4. Good point One thing you mentioned in point number one has me thinking as well. You wrote, "presumably both Logos and Accordance would run faster" Not necessarily, Logos uses a different engine to run searches. It is possible that the recording program used by this guy impacted the Logos architecture and not the Accordance architecture. As it is, the video is admittedly flawed (as admitted in the comments section of the post).

John McComb:

I already said this once in a different thread on a different forum but I think it bears repeating. The search wasn't slow. The search completed in the blink of an eye. It was the updating of the results in the search results window that was slow and that's a consequence of the IE browser interface. That interface is being tossed out anyway, as Bob says above (although I doubt very much that I will install that version if it's going to break all my tools as hinted earlier).

Anyway, who waits for the search results window to fill up. It's hardly necessary. In fact, in the case of the simple bible search that the guy was demonstrating, all of the results are highlighted in the bible resource window almost instantaneously so I don't even need the search results window.

For Bible Search I don't view the hits in context in Search Results as I choose the Simple List option (Windows version) - so that many searches update almost instantly, together with the highlighting in the resource! That's always been my workaround for the slow HTML   [more later]

-------

Speed was a major consideration for Windows users prior to v3, which provided a mix of search improvements and slower reports, but it ceased to be the major topic of earlier years. That "maturing" seems to be already present with users of the Mac version where the lack of features has been the major topic in the newsgroups and forum. But I was shocked to view evidence that is so familiar to users of the Windows version and then relieved to read Bob's admission that things would only get better  - we've known for some time that v4 for Windows would be vastly improved.