Vista's Natural Language Search is Sloooow

A few months ago - in May - I turned on Natural Language Search in Vista.

I thought it was a good idea.

I didn't notice anything initially, just a failure to work very well when I tried things like "all documents created yesterday."

In June, I installed Windows Search 4.0. I noticed no speed up; if anything, the speed was terrible.

Today, once again waiting for the start menu search to respond after 10 seconds, I finally had enough and set out to make search faster. Needless to say, the first thing I did was go and restore defaults.

Which lead me to disable Natural Language Search.

Which lead to Vista's search response time going from 10+ seconds to under 1 second.

I must conclude that the Natural Language Search option is really bloody slow.

Seriously, what kind of parsing is Windows doing? I can think of a few things I'd like it to do - entity extraction in search string matched to entities extracted from documents, common language components, e.g. support for "all," "only", etc - but how on earth does that take 10 to 15 seconds?

Anyone else get the same speed decrease when Natural Language Search is enabled?

tell ... me... about it.



*looks like bill gates deposition...

(humor!)

Parsing is pretty much istantaneous. What would be interesting is the see the final query as it's sent to the index.... I can take a stab at figure that out tomorrow, but Brandon probably knows better than me how to do that

It not only sloooow... It's wroooooong as well.

BHpaddock said:

BlackTiger said:

*snip*

In what way?

*handwaves*

BHpaddock said:

Parsing should take exactly the same amount of time whether it's using NQS (natural language queries) or AQS (regular searches / advanced query syntax).

If you're waiting 10-15 seconds for search results something is wrong.  How many items are in your index according to the control panel?

What sort of machine specs are we talking about?

That's precisely what I would have expected - NQS taking no extra time - it's simply not what I'm experiencing.

I'm running a Dell Latitude D620; Intel Core Duo 2.0 GHz, 2 GB RAM; 80 GB 7200-RPM HD; Vista 32-bit. I have 56,077 items in my index, according to your Sidebar gadget. This is a rather small index; at least to my thinking.

If I turn Natural Language search, my minnimum time for a search jumps to 5 seconds, with searches of up to 15 seconds (for 3 word queries!) occuring with some regularity. This compares to under a second without NQS.

It also fails to find basic things; if I search for "movie" it won't find Windows Movie Maker. Search for "photo," it doesn't find Windows Photo Gallery (or Windows Live Photo Gallery), etc. Things like that. AQS works perfectly; finds everything.

Michael Griffiths said:

BHpaddock said:

*snip*

That's precisely what I would have expected - NQS taking no extra time - it's simply not what I'm experiencing.

I'm running a Dell Latitude D620; Intel Core Duo 2.0 GHz, 2 GB RAM; 80 GB 7200-RPM HD; Vista 32-bit. I have 56,077 items in my index, according to your Sidebar gadget. This is a rather small index; at least to my thinking.

If I turn Natural Language search, my minnimum time for a search jumps to 5 seconds, with searches of up to 15 seconds (for 3 word queries!) occuring with some regularity. This compares to under a second without NQS.

It also fails to find basic things; if I search for "movie" it won't find Windows Movie Maker. Search for "photo," it doesn't find Windows Photo Gallery (or Windows Live Photo Gallery), etc. Things like that. AQS works perfectly; finds everything.

It also fails to find basic things; if I search for "movie" it won't find Windows Movie Maker. Search for "photo," it doesn't find Windows Photo Gallery (or Windows Live Photo Gallery), etc. Things like that. AQS works perfectly; finds everything.

Well, I know the answer to this one

In NQS, a query like "photo of Venice" will be interpreted as "CONTAINS("Venice") AND kind='photo'" (or something similar ). This means that certain keywords like photo, music, movie, etc are overloaded in meaning as to indicate the type of item you're looking for.

Also, if your type "note" in AQS, you get Notepad.exe, in NQS you don't (kind='note')

It's a somehow odd behavior that we're tracking and thinking on how to improve or make more understandable.

Works just fine for me. 1-2 second response.

PaoloM said:

Michael Griffiths said:

*snip*

Well, I know the answer to this one

In NQS, a query like "photo of Venice" will be interpreted as "CONTAINS("Venice") AND kind='photo'" (or something similar ). This means that certain keywords like photo, music, movie, etc are overloaded in meaning as to indicate the type of item you're looking for.

Also, if your type "note" in AQS, you get Notepad.exe, in NQS you don't (kind='note')

It's a somehow odd behavior that we're tracking and thinking on how to improve or make more understandable.

Wouldn't it be more pragmatic to let people type in say... raw SQL? (or some more appropriate search instruction).

You get the benefit of knowing exactly what the computer is searching for, simpler parsing, and if it's well done it should closely resemble English anyway.

W3bbo said:

PaoloM said:

*snip*

Wouldn't it be more pragmatic to let people type in say... raw SQL? (or some more appropriate search instruction).

You get the benefit of knowing exactly what the computer is searching for, simpler parsing, and if it's well done it should closely resemble English anyway.

You can:

http://msdn.microsoft.com/en-us/library/bb231256(VS.85).aspx">http://msdn.microsoft.com/en-us/library/bb231256(VS.85).aspx

.... just not in the main interface. It'd be rather trivial to create an interface to return the results of a SQL statement.

Most people, needless to say, don't know SQL; and while I'd love some of the features (group, rank) I don't really want to type a long SQL statement for a rather simple query.

_______________________

Paolo, it's interesting that keywords like that are so hardcoded. Natural Language is a bit more ambiguous than that; I'd expect something more along the lines of defaulting to searching for the word, and only using certain words-as-types when the grammer supports it (I would assume you have some sort of grammer parser that deconstructs the search string).

Or doing both - returning all "movies" while at the same time returning everything that contains "movies." i.e. the more general the search is, the more general the query and this the results. A highly specific one (e.g. "all emails sent to microsoft yesterday") would also be easier to parse and "get" accurately, because there's more natural language detail.

Michael Griffiths said:

W3bbo said:

*snip*

You can:

http://msdn.microsoft.com/en-us/library/bb231256(VS.85).aspx">http://msdn.microsoft.com/en-us/library/bb231256(VS.85).aspx

.... just not in the main interface. It'd be rather trivial to create an interface to return the results of a SQL statement.

Most people, needless to say, don't know SQL; and while I'd love some of the features (group, rank) I don't really want to type a long SQL statement for a rather simple query.

_______________________

Paolo, it's interesting that keywords like that are so hardcoded. Natural Language is a bit more ambiguous than that; I'd expect something more along the lines of defaulting to searching for the word, and only using certain words-as-types when the grammer supports it (I would assume you have some sort of grammer parser that deconstructs the search string).

Or doing both - returning all "movies" while at the same time returning everything that contains "movies." i.e. the more general the search is, the more general the query and this the results. A highly specific one (e.g. "all emails sent to microsoft yesterday") would also be easier to parse and "get" accurately, because there's more natural language detail.

I was using SQL as an example. But I'm thinking of something like AppleScript: it resembles English language anyway, but it's a very strongly structured language that has zero ambiguity.

But anyway, how about introducing a simple criteria engine that accepts data like so:

"type={extension or mime-type},contains={wildcard or regular expression},in={directory wildcard},modb4={date}"

W3bbo said:

Michael Griffiths said:

*snip*

I was using SQL as an example. But I'm thinking of something like AppleScript: it resembles English language anyway, but it's a very strongly structured language that has zero ambiguity.

But anyway, how about introducing a simple criteria engine that accepts data like so:

"type={extension or mime-type},contains={wildcard or regular expression},in={directory wildcard},modb4={date}"

Doesn't Windows Search already accept simple criteria?