Logos 4.0d suggestion: Optimise phrase searching

Logos 4 is superfast for most searching, but very slow with phrase searching. Take the following example:

"look out for the dogs, look out for the evildoers" which takes about 30s in my library. That's too long.
but dogs NEAR look NEAR evildoers takes 0.55s - that's one sixtieth of the time!

Now it seems to be that if you can find the latter search in such a short time, it surely must be possible to optimise the former one some how.

Find more posts tagged with

Comments

TCBlack

I agree Mark. I typically do phrase searching so your suggestion resonates with me.

Bob Pritchett

Try a phrase without "the" in it. :-)

Because of memory limitations, we store the index on the hard drive. When you search for a phrase with "the" in it, we need to load and check every instance of "the" in your entire library against the position of the adjacent words in your query.

We spend a lot of time reading and studying the art of full-text information retrieval. There are solutions that make searching for "the" (and other "stop words") faster, but they all involve less precision. Over the year our users have objected to some of these time saving techniques. (The classic one is to simply ignore the stop words.)

There are also probabilistic search techniques that are faster, but which sometimes return false hits or miss hits. We chose not to use these, too.

There are probably some small optimizations we can do, but the bottom line is that if you want precise phrase searches (which our users told us they do, back when we didn't have them!), there's simply no avoiding looking at all the hits. We already use compression and smart algorithms to try and reduce disk time in loading and analyzing those hits.

Google helps address this by keeping thousands of computers running 24x7 with (according to what I've read) the entire Internet in memory. The small-time equivalent for Logos users would be to use a solid-state hard drive, but that is still an expensive option.

(Our developers use an SSD for a small compiling/working drive, and a slower, traditional hard drive for data files.)

Rosie Perera

https://community.logos.com/discussion/comment/134897#Comment_134897

Why not do a two-pass solution? Ignore all the stop words for the first pass and then check the hits that resulted from the first pass against the actual search string? That would probably end up being faster than the current solution and wouldn't involve a loss of precision.

JimTowler

https://community.logos.com/discussion/comment/134899#Comment_134899

Why not do a two-pass solution?

YES !!!

Run the first scan on some uncommon word to make the first list. Then run the full "slow" but complete search only on the 1st hit list. The rule could be to run the first pass using the longest word or something simple.

(Same for expanding a book in the search. Only look within that book. I.E. Code to support two-pass, and it may well share most or much of whats already in place for searching collections, Passage Lists, Notes etc. Good reusable plumbing ...)

Rosie Perera

https://community.logos.com/discussion/comment/134910#Comment_134910

Run the first scan on some uncommon word to make the first list. Then run the full "slow" but complete search only on the 1st hit list. The rule could be to run the first pass using the longest word or something simple.

I would run the first pass on all the non-trivial words in the phrase ANDed together. That will be super fast and will weed down the number of hits significantly over just using one word. Then you can do the full "slow" phrase search within the resulting hit list. Should be able to bring a 30-second search down to just a few seconds at most, except for short phrases that have nothing but very common words in them.

JimTowler

https://community.logos.com/discussion/comment/134912#Comment_134912

The issue here is with complex AND, OR, NOT, NEAR etc rules.

Pass One would need to ALWAYS got the super-set of all possible resources (or smaller breakdown) that might ever be in the final answer.

THEN, pass two could be as complete, painful, and slow as it needs to get the exact results of whatever query the user requested, but it would only need to run against the first superset of possible hits. Even if the first pass was to only build a per-resource list, that might be enough for the needed improvements.

Already, we know that Logos4 does not have a solid syntax parser, given the strange and unexpected results people get if they feed it a "bad" query. If the parser was most strict, it could generate the control inputs needed for both passes, as it would "understand" what had been requested.

A few days ago, I searched something like [""the quick brown fox"] and it found "the" and "fox" etc all over the place. On account of the double-quote, it acted in an unexpected way. Maybe better if I got an error, beep, or some kind of feedback, in place of a bad search.

MJ. Smith

https://community.logos.com/discussion/comment/134919#Comment_134919

If the parser was most strict, it could generate the control inputs needed for both passes, as it would "understand" what had been requested.

I would like very much to be able to see the actual query generated in strict logical form. At the moment it is difficult to determine if my search failed because it was poorly formed or because I ran into a Logos bug. I know that this would not be useful to many Logos users but I think the payoff to Logos would be worth it - we could actually give accurate advice on the forums.[:P]

Okay, casual reader. Most of your queries are working fine. It is in the combination of operators in the query that we can force unusual results.

Mark Barnes

https://community.logos.com/discussion/comment/134899#Comment_134899

Why not do a two-pass solution?

A multi-pass solution is the obvious optimisation, though I appreciate it's difficult to code. It's easy for a human to know that dogs NEAR look NEAR evildoers would make a good first pass because both words a relatively uncommon (at least compared to look, our, for, the) - though I still have more than 11,500 dogs in my library!

But if your index kept a note of the frequency of words, then Logos itself could perform the optimisation for phrase searching - it do a WITHIN x WORDS search for the least frequent words, and then just search the results.

With AND searches, the part of the query that should yield the least results could be identified and run first, and other parts of the query run on a subset of those results.

Somehow other search engines manage to optimise for phrase-searching. It must be possible.

Rosie Perera

https://community.logos.com/discussion/comment/134932#Comment_134932

I still have more than 11,500 dogs in my library!

Goodness! Let them out. They're probably all peeing on the floor in there!

Mark Barnes

https://community.logos.com/discussion/comment/134936#Comment_134936

Goodness! Let them out. They're probably all peeing on the floor in there!

It's OK. They're well behaved [:D]

Jon

https://community.logos.com/discussion/comment/134897#Comment_134897

Because of memory limitations, we store the index on the hard drive

I'm out of my depth in terms of thinking through how you'd code something like this to accommodate different computer specs but could you change this behaviour depending on available RAM? My bible index is ~750mb, my systems have 6gb and 8gb of RAM and it is rare that more than 50% is used except when video editing and encoding. I for one would be perfectly happy if Logos4 used up its potential (32-bit limited) 4gb and cached my bible index, bibles and other frequently used books. [:)]

Jon

https://community.logos.com/discussion/comment/135356#Comment_135356

Hmmm... there may be other bottlenecks, I decided to test my own theory:

Setup one: normal Logos installation (on 2 x 750gb RAID 0 array)

Setup two: created RAMdisk, placed the LibraryIndex on it and mounted it into the LibraryIndex folder.

Results for Mark's search:

1: 29s

2: 29s

Hmm... [:O]

Mark Barnes

https://community.logos.com/discussion/comment/135362#Comment_135362

Hmm...

I'm fairly sure that the index only includes pointers to other resources, and that for phrase searching Logos has to actually open the resource to check the result. If I'm right, then you'd have to copy all your resources into memory to see a speed increase. (Also, as a minimum you'd also want to add BibleIndex to your RAM Drive.)

Also, my LibraryIndex and BibleIndex is more than 5Gb. Even if I could spare 6Gb (which I can't - it's all I have!), just copying that into RAM takes a long time. It's probably not worth it.

Dave Hooton

https://community.logos.com/discussion/comment/135369#Comment_135369

I'm fairly sure that the index only includes pointers to other resources,

other?

for phrase searching Logos has to actually open the resource to check the result.

After studying disk activity in Resource Monitor all resources with the expected results are opened but I didn't see others being opened!

But phrase search is interesting as it will search footnotes and glosses for an exact match within the footnote or within the gloss of a single manuscript word, which is something you cannot do with a proximity search! For example the BEFORE 1 word evildoers will find results from the glosses of adjacent manuscript words whereas "the evildoers" will find the exact match from the gloss of a single manuscript word.

Mark Barnes

https://community.logos.com/discussion/comment/135678#Comment_135678

other?

Sorry, I meant "I'm fairly sure that the index only includes pointers to the actual resources".

Regarding proximity searching, I'm pretty sure position is always measure in relation to the surface text, so your finding would make sense.

Matthew C Jones

https://community.logos.com/discussion/comment/134924#Comment_134924

I would like very much to be able to see the actual query generated in strict logical form. At the moment it is difficult to determine if my search failed because it was poorly formed or because I ran into a Logos bug. I know that this would not be useful to many Logos users but I think the payoff to Logos would be worth it - we could actually give accurate advice on the forums.

Me too. And it would be nice to have a Wiki tutorial on how to construct strict logical searches. I learned a few new ideas at Morris Proctor's Camp Logos on how to construct different searches. Sometimes I get weird results because I didn't think through my query.

Have you ever noticed Logos.Bible.com appears to use a fuzzy-logic in returning search results? When I type a phrase there my search phrase is almost always worded from the KJV or NASB vocabulary. Even though the ESV is the version searched I get hits consistent with my preferred versions. I have not observed this behavior within my Logos program, only with the online Logos search. Is there a version cross-referencing going on behind the scenes? If so, is it possible to duplicate a wider fuzzy search within the Logos program if desired? I'm guessing searching multiple Bibles is the closest I can get.

Mark Barnes

https://community.logos.com/discussion/comment/135702#Comment_135702

I would like very much to be able to see the actual query generated in strict logical form. At the moment it is difficult to determine if my search failed because it was poorly formed or because I ran into a Logos bug. I know that this would not be useful to many Logos users but I think the payoff to Logos would be worth it - we could actually give accurate advice on the forums.

Me too.

I agree with this, and I vaguely remember someone from Logos saying that they were working towards it. Actually, my preference would be to educate the user by suggesting the correct form of the search. So, for example, if someone searched for (cat OR dog) NEAR (evil OR good), Logos would say Did you mean (cat, dog) NEAR (evil OR good)?. Likewise for missing parentheses, lowercase operators like within, etc. Ideally, there would also be an explain button, so they could see why Logos wanted to make the correction.

That way it's only an extra click for users, but they learn how to do them properly.

Robert Pavich

https://community.logos.com/discussion/comment/135704#Comment_135704

Actually, my preference would be to educate the user by suggesting the correct form of the search. So, for example, if someone searched for (cat OR dog) NEAR (evil OR good), Logos would say Did you mean (cat, dog) NEAR (evil OR good)?. Likewise for missing parentheses, lowercase operators like within, etc. Ideally, there would also be an explain button, so they could see why Logos wanted to make the correction.

That way it's only an extra click for users, but they learn how to do them properly.

As one uneducated user...I say yes to this suggestion...(I've had Dave and Mark try and explain it all to me more than once..!)

spitzerpl

https://community.logos.com/discussion/comment/135712#Comment_135712

would it be possible for the search box to somehow indicate that a given word is one of these "stop" words? Maybe turn it red with a little floater that says you might get better/faster results if you don't include this word?

Bob Pritchett

https://community.logos.com/discussion/comment/134899#Comment_134899

Why not do a two-pass solution? Ignore all the stop words for the first pass and then check the hits that resulted from the first pass against the actual search string? That would probably end up being faster than the current solution and wouldn't involve a loss of precision.

We don't open the resources to check the phrase. We read the hit list. The hit list is stored in one long list, with each book's hits one after another. Smart "skip" logic already avoids checking unnecessary resources. (Though there may be more optimization we can do, at a trade off of taking more space.)

Checking the rarer words first, and then using their less frequent documents lists to speed up scanning of the more common words hit lists is a classic optimization, and I believe we've already implemented it. (This does what the two-pass would do, only more efficiently.)

If you're really interested in this, I'd suggest the book "Managing Gigabytes," by Witten, Moffat, and Bell.

Dave Hooton

https://community.logos.com/discussion/comment/135768#Comment_135768

Checking the rarer words first, and then using their less frequent documents lists to speed up scanning of the more common words hit lists is a classic optimization, and I believe we've already implemented it. (This does what the two-pass would do, only more efficiently.)

Thanks for that info Bob. I'm very impressed with the way a phrase search works and would trust that Search will be made easier by appropriate parsing and a suggested restructuring to avoid invalid queries.

Bob Pritchett

https://community.logos.com/discussion/comment/135817#Comment_135817

Thanks for that info Bob. I'm very impressed with the way a phrase search works and would trust that Search will be made easier by appropriate parsing and a suggested restructuring to avoid invalid queries.

Logos 3 parsed your query on every keystroke and turned the search edit box border red whenever the query was in an invalid state.

User feedback, and our reading of academic research, revealed that only a small number (< 2%) of users EVER use a boolean operator, and that most people expect (and prefer) a search system like Google's.

So in Logos 4 we implemented a very forgiving parser, and removed the requirement of any syntax. If you do something that does parse, we run it through the "formal" system; otherwise (like Google), we treat it as a "bag of words".

The one place this fails is if you thought you were typing something formal, and just slightly messed it up. I believe we had an early spec that showed you how the system interpreted your query, right down to wildcard expansion, but it got messy, and sometimes the formal rendering of the parsing looked so different it could be confusing. We cut this to avoid duplication and because we were running out of time.

One option would be to only show the formal rendering when we formally parsed a tree; then you'd realize that if you didn't get the rendering you'd know we hadn't parsed what you meant. Another option would be to get "smarter", and detect more common errors, like Google does with likely spelling mistakes, typos, etc. The first parts of this are shown in our optional query expansions for topical words; internally we have early (but still not perfected) implementations of "Did you mean correct spelling?" up and running.

We'll be revisiting query parsing (and planning next generation search features) later this summer, and we'll put some more energy into making it even easier.

Mark Barnes

https://community.logos.com/discussion/comment/135895#Comment_135895

Another option would be to get "smarter", and detect more common errors, like Google does with likely spelling mistakes, typos, etc. The first parts of this are shown in our optional query expansions for topical words; internally we have early (but still not perfected) implementations of "Did you mean correct spelling?" up and running.

I've argued for this elsewhere as the best solution. It should include errors like not putting WITHIN in capitals, missing parethesis, and invalid proximity searches like (a OR b) NEAR (c OR d), which should be corrected to (a, b) NEAR (c, d)

JimTowler

https://community.logos.com/discussion/comment/135895#Comment_135895

... later this summer ...

When is summer?

Its early Winter here. Please use month names or something for your international customers.

Rosie Perera

https://community.logos.com/discussion/comment/135903#Comment_135903

I've argued for this elsewhere as the best solution. It should include errors like not putting WITHIN in capitals, missing parethesis, and invalid proximity searches like (a OR b) NEAR (c OR d), which should be corrected to (a, b) NEAR (c, d)

I'm glad the idea is to do this as a suggestion: "Did you mean ___ ?" because there are legitimate times when you might spell a special search word in lower case and not mean it as a special search word. For example whoever before heaven is a legitimate search in its own right, and it means something quite different from whoever BEFORE heaven. I wouldn't want it automatically corrected for me. When Google detects a possible misspelling, it goes ahead and deos the search anyway, as you typed it, but gives you the opportunity to easily rerun the search with the corrected spelling if you choose. That's the way I'd hope Logos would do this.

Why should (a OR b) NEAR (c OR d) be considered an invalid search? I know it doesn't work currently, while (a, b) NEAR (c, d) does. But that seems to me to be a bug. The user shouldn't be forced to use a comma when OR and comma are supposed to be synonyms.

Dave Hooton

https://community.logos.com/discussion/comment/135908#Comment_135908

Why should (a OR b) NEAR (c OR d) be considered an invalid search? I know it doesn't work currently, while (a, b) NEAR (c, d) does. But that seems to me to be a bug. The user shouldn't be forced to use a comma when OR and comma are supposed to be synonyms.

Bradley has explained the logical (OR) vs. physical (NEAR) incompatibility and indicated that he would allow that type of search to work as the user intended, so there should be no hinting "Did you mean ...".

Rosie Perera

https://community.logos.com/discussion/comment/135915#Comment_135915

Why should (a OR b) NEAR (c OR d) be considered an invalid search? I know it doesn't work currently, while (a, b) NEAR (c, d) does. But that seems to me to be a bug. The user shouldn't be forced to use a comma when OR and comma are supposed to be synonyms.

Bradley has explained the logical (OR) vs. physical (NEAR) incompatibility and indicated that he would allow that type of search to work as the user intended.

I don't get it. Either there's an incompatibility between OR and NEAR, or Bradley can make that type of search work as the user intended. I don't see how it can be both. I do remember a thread explaining why (a,b) NEAR c works while (a OR b) NEAR c doesn't, but I don't remember why and can't find the thread.

Todd Phillips

https://community.logos.com/discussion/comment/135908#Comment_135908

Why should (a OR b) NEAR (c OR d) be considered an invalid search? I know it doesn't work currently, while (a, b) NEAR (c, d) does. But that seems to me to be a bug. The user shouldn't be forced to use a comma when OR and comma are supposed to be synonyms.

They aren't supposed to be synonyms--they just seem like it. Bradley has made this point before. The comma list is one term logically, whereas the OR clause just generates a boolean value that has no meaning when used with a NEAR operator ( Does "true NEAR true" mean anything?)

See here for where he discusses this and says they have plans to make the parsing figure things out better:
http://community.logos.com/forums/p/4896/72043.aspx#72043

Dave Hooton

https://community.logos.com/discussion/comment/135903#Comment_135903

Another option would be to get "smarter", and detect more common errors, like Google does with likely spelling mistakes, typos, etc. The first parts of this are shown in our optional query expansions for topical words; internally we have early (but still not perfected) implementations of "Did you mean correct spelling?" up and running.

I've argued for this elsewhere as the best solution. It should include errors like not putting WITHIN in capitals, missing parethesis, and invalid proximity searches like (a OR b) NEAR (c OR d), which should be corrected to (a, b) NEAR (c, d)

I agree with the "smarter" approach which might also provide an option for possibly ambiguous queries like a OR b AND c OR d eg. "Did you mean (a OR b) AND (c OR d)?" otherwise run as written.

Kevin Becker

https://community.logos.com/discussion/comment/135906#Comment_135906

... later this summer ...

When is summer?

Its early Winter here. Please use month names or something for your international customers.

In the US Summer is June, July, and August.

Dave Hooton

https://community.logos.com/discussion/comment/135917#Comment_135917

I don't get it. Either there's an incompatibility between OR and NEAR, or Bradley can make that type of search work as the user intended. I don't see how it can be both.

Sorry, Rosie - that was a poor "explanation".

This might have been better "Bradley has explained the
incompatibility between the output of a Boolean expression (OR, AND) and a proximity term (BEFORE, NEAR) but it is still possible to make that type of search work as the user intended.", however Todd has provided a more complete explanation.

Matthew C Jones

https://community.logos.com/discussion/comment/135949#Comment_135949

In the US Summer is June, July, and August.

Not really. It is June 21st through September 20th. Astronomically based, of course. [S] [*]

And since God told us the heavenly lights were for signs, I'd defer to Genesis over my local school board's schedule . [C]

Kevin Becker

https://community.logos.com/discussion/comment/135966#Comment_135966

Not really. It is June 21st through September 20th. Astronomically based, of course.

And since God told us the heavenly lights were for signs, I'd defer to Genesis over my local school board's schedule .

I knew someone would go and look up the specifics! [:D]

Matthew C Jones

https://community.logos.com/discussion/comment/136018#Comment_136018

I knew someone would go and look up the specifics!

I didn't need to look it up.

My father bought me a telescope for my 12th birthday and took me to the top of Mt Zao to show me the rings of Saturn. It sparked a love of astronomy in my young heart. The telescope is long gone but the memory is treasured forever.

JimTowler

https://community.logos.com/discussion/comment/136018#Comment_136018

Thanks for the answers re summer.

I never get why mags come out titled "Fall 2010 Issue" or something. I never know when that is or when to expect the next one.

Its Winter here, a massive strorm outside, very wet and windy, and 4:38 am Tuesday. See my problem.

Mark Barnes

https://community.logos.com/discussion/comment/135917#Comment_135917

I don't get it. Either there's an incompatibility between OR and NEAR, or Bradley can make that type of search work as the user intended. I don't see how it can be both. I do remember a thread explaining why (a,b) NEAR c works while (a OR b) NEAR c doesn't, but I don't remember why and can't find the thread.

OR and comma are not the same, though they give the same results in some situations. This is from the Wiki:

Using lists

Lists are a very useful feature which provide shortcuts in a number
of searches. A list is written like this: (term1, term2, term3,
etc.). When Logos encounters a list, it performs the search
using just term1. Then it repeats the search using just term2, then with
just term3, etc. Once it has finished, it then ORs the
results. Here are some examples:

(Jesus, Christ) is equivalent to Jesus
OR Christ
(Jesus, Christ) AND love is equivalent to (Jesus
AND love) OR (Christ AND love)

Lists are most useful when used with fields (see
below), or when trying to ensure proximity operators are only used in
the outer terms of your search. For example:

The search described earlier (master NEAR love) OR
(master NEAR serve) OR (neighbor NEAR love) OR (neighbor NEAR serve)
can be simplified to (master, neighbor) NEAR (love, serve).
Logos treats the two lists separately, iterating through them until
every combination as been reached, like this:
- master NEAR love
- master NEAR
  serve
- neighbor NEAR love
- neighbor
  NEAR serve

Please note: Some people get confused as they equate the list
with the OR command. They are not the same, even though in a very basic
search they will perform in the same way. Remember, Logos iterates
through lists, then ORs the results.

Ron

https://community.logos.com/discussion/comment/136050#Comment_136050

OR and comma are not the same, though they give the same results in some situations. This is from the Wiki:

So the short version is that 99% of the time we should be using commas instead of ORs in our searches?

Can anyone explain to me a case where using OR would be correct and appropriate?

Mark Barnes

https://community.logos.com/discussion/comment/136067#Comment_136067

I can't think of any situation where you mean OR, but where a comma wouldn't produce the result you intend - so the 'safest' course of action would be to always use commas. Commas will always give you the results you expect. (But that doesn't mean you should be using commas. OR is not incorrect most of the time.)

The reason why it's wrong some of the time is that OR is a boolean logical operator. In logic, a OR b either produces TRUE or FALSE. It can have no other result. In Logos, searching for Jesus OR Christ will return TRUE if the article contains one of those words, FALSE if the article contains neither of those words. After a search, Logos lists all the articles that are TRUE. This is quite satisfactory and quite correct. It's exactly what we want.

But what if you type (Jesus OR Christ) NEAR (love OR compassion)? The left-hand side is evaluated, and let's imagine returns the result TRUE. Then the right-hand side is evaluated. Let's imagine that returns TRUE as well. So we're left with TRUE NEAR TRUE. Logically, that makes no sense, hence Logos returns no results for that time of search.

Mark Barnes

https://community.logos.com/discussion/comment/136023#Comment_136023

Its Winter here, a massive strorm outside, very wet and windy, and 4:38 am Tuesday. See my problem.

Sounds to me like your problem is insomnia! [:)]

Ron

https://community.logos.com/discussion/comment/136086#Comment_136086

I can't think of any situation where you mean OR, but where a comma wouldn't produce the result you intend - so the 'safest' course of action would be to always use commas. Commas will always give you the results you expect. (But that doesn't mean you should be using commas. OR is not incorrect most of the time.)

The reason why it's wrong some of the time is that OR is a boolean logical operator. In logic, a OR b either produces TRUE or FALSE. It can have no other result. In Logos, searching for Jesus OR Christ will return TRUE if the article contains one of those words, FALSE if the article contains neither of those words. After a search, Logos lists all the articles that are TRUE. This is quite satisfactory and quite correct. It's exactly what we want.

But what if you type (Jesus OR Christ) NEAR (love OR compassion)? The left-hand side is evaluated, and let's imagine returns the result TRUE. Then the right-hand side is evaluated. Let's imagine that returns TRUE as well. So we're left with TRUE NEAR TRUE. Logically, that makes no sense, hence Logos returns no results for that time of search.

Ahhh...that makes sense now. Thanks for the great explanation Mark. [;)]

Bradley Grainger (Logos)

Logos 4 is superfast for most searching, but very slow with phrase searching. Take the following example:

"look out for the dogs, look out for the evildoers" which takes about 30s in my library. That's too long.

but dogs NEAR look NEAR evildoers takes 0.55s - that's one sixtieth of the time!

Now it seems to be that if you can find the latter search in such a short time, it surely must be possible to optimise the former one some how.

Rosie Perera

https://community.logos.com/discussion/comment/197369#Comment_197369

Logos 4 is superfast for most searching, but very slow with phrase searching. Take the following example:

"look out for the dogs, look out for the evildoers" which takes about 30s in my library. That's too long.

but dogs NEAR look NEAR evildoers takes 0.55s - that's one sixtieth of the time!

Now it seems to be that if you can find the latter search in such a short time, it surely must be possible to optimise the former one some how.

Hmm, Bradley you must be using a very small library and an extremely fast machine. I know my machine is slower than most, but I'd be happy with 10 or 20 or even 30 seconds! Here's my result for the same search (EDIT: This is in 4.2 RC 2):

Dave Hooton

https://community.logos.com/discussion/comment/197374#Comment_197374

7.5s in 4.2 vs. 10.4s in 4.1, both on the Desktop [:|]

Robert Pavich

https://community.logos.com/discussion/comment/197381#Comment_197381

12 seconds for my aging 1.9 Core Duo with a 1 GB video card

Milford Charles Murray

https://community.logos.com/discussion/comment/197398#Comment_197398

Peace to all! *smile*

Mine took 96.4 seconds. Have almost 3,000 resources.

OS Name Microsoft Windows XP Professional
Version 5.1.2600 Service Pack 3 Build 2600
OS Manufacturer Microsoft Corporation
System Name THEFUTUREISNOW
System Manufacturer Dell Inc.
System Model Dell DXG051
System Type X86-based PC
Processor x86 Family 15 Model 4 Stepping 3 GenuineIntel ~3392 Mhz
BIOS Version/Date Dell Inc. A06, 10/02/2006
SMBIOS Version 2.3
Windows Directory C:\WINDOWS
System Directory C:\WINDOWS\system32
Boot Device \Device\HarddiskVolume2
Locale Canada
Hardware Abstraction Layer Version = "5.1.2600.5512 (xpsp.080413-2111)"
User Name THEFUTUREISNOW
Time Zone Eastern Standard Time
Total Physical Memory 4,096.00 MB
Available Physical Memory 795.04 MB
Total Virtual Memory 2.00 GB
Available Virtual Memory 1.96 GB
Page File Space 7.84 GB
Page File C:\pagefile.sys

Rosie Perera

https://community.logos.com/discussion/comment/197398#Comment_197398

7.5s in 4.2 vs. 10.4s in 4.1, both on the Desktop

12 seconds for my aging 1.9 Core Duo with a 1 GB video card

Mine took 96.4 seconds. Have almost 3,000 resources.

Hmm, I wonder if it has something to do with how many resources we have, not just how fast our machines are? Dave, Robert how many resources do you have? I have over 4,000. So my timing would make some sense proportionally with Milford's.

Dave Hooton

https://community.logos.com/discussion/comment/198168#Comment_198168

Hmm, I wonder if it has something to do with how many resources we have, not just how fast our machines are? Dave, Robert how many resources do you have?

The second figure for v4.1 on the same computer should indicate whether Bradley was boasting about an improvement in search speed for 4.2. But my times today were 7.0s (4.2) and 7.2s (4.1, achieved during startup!), so it grows increasingly unlikely.

I have 972 resources.

Rosie Perera

https://community.logos.com/discussion/comment/198172#Comment_198172

Hmm, I wonder if it has something to do with how many resources we have, not just how fast our machines are? Dave, Robert how many resources do you have?

The second figure for v4.1 on the same computer should indicate whether Bradley was boasting about an improvement in search speed for 4.2. But my times today were 7.0s (4.2) and 7.2s (4.1, achieved during startup!), so it grows increasingly unlikely.

I have 972 resources.

Wow! I would give almost anything for 7 second phrase search times! Except I wouldn't give away over 3000 of my Logos resources. :-)

Mark Barnes

https://community.logos.com/discussion/comment/198175#Comment_198175

Remember that caching can help. I got 38.3s in a first run, 29s on subsequent runs. My library size is similar to Rosie's. I do wonder whether the relatively slow speeds we're suffering from are partly due to the relevant part of our large library indexes not being able to be held in memory.

Dave Hooton

https://community.logos.com/discussion/comment/198178#Comment_198178

Remember that caching can help.

I usually take the first attempt after a startup. Another go with 4.1/4.2 shows that my 7s times vary by no more than +0.5s.

EDIT: to simplify that, my times are in the range 7s to 7.5s