4 ms·

I have seen so many applications like this, and they seem to miss that the backend of windows search is actually pretty amazing, and has providers for a multitu

I have seen so many applications like this, and they seem to miss that the backend of windows search is actually pretty amazing, and has providers for a multitude of file types both binary and text, which allows for full content search and not just file name, title, and description. The truth is too its actually really easy to access programmatically. Instead of them rolling their own indexer, they should use something like elastic which has an on par number of providers for various file types.

jjoonathan 7y ago
If the backend of Windows Search is amazing, why is the front-end user experience abysmal? The problems just don't seem like front end problems: the search is occasionally slow, it doesn't even reliably find installed programs by their name, and if the result pops up while your next keystroke is underway it will sometimes lose the result even if that keystroke is correct, and somehow finding the result again will require removing more than the single correct keystroke that made your desired result disappear. The mind boggles. I'm not familiar with Windows internals, so I should clarify: I'm talking about the search functionality invoked by typing after pressing the Windows key. If I were an app developer in this space I would not trust my core functionality to anything even remotely associated with the above, and I strongly suspect that the complexity of handling the long tail of functionality you mentioned has something to do with why the windows-key search experience sucks. Certainly the fundamental task is not intractable because Spotlight (Apple's search) has been Good Enough for a while. IIRC it became tolerable around the time SSDs became standard. Windows-key search isn't quite there yet. Until it is, I'll take good execution on the basic 80% of functionality any day.
- Meph504 7y ago
  The front end is a mystery to me, windows search backend is a queryable system, it's reliable, impressively fast, and suffers from none of the issues that have plagued not only the win10 search, but windows explorer as well. I've never understood why it's performance has been deemed acceptable. I'm on my phone right now so forgive the random sample, but this gives the gist of its usage. https://stackoverflow.com/a/34340288 https://stackoverflow.com/a/34340288 The only issue I have seen is when the index corrupts, this was more common in win7, and in our research it was often the result from an over aggressive AV jamming up the process. But I've written a number of systems that make use of this, and when comparing other ways to accomplish this sort of in depth search, it's the most reliable and manageable. It does have the caveat that it works best on places indexed by the OS, and adding locations to the indexer via code requires some pinvoke stuff most people aren't comfortable with.
- buckminster 7y ago
  There seems to be more than one index. There is the index of scanned file content, an index for apps, and maybe another one for help. There is also a query timeout. If you start searching after a boot on a slow laptop you get a subset of results dependent on which index is loaded before the query times out. Kill the start menu and try again. And again. And then it works smoothly. It's quite poor.
EdwardDiego 7y ago
Wait, by Elastic, do you mean Elasticsearch? Genuinely curious, as I've only ever used it for large scale log ingestion/APM etc. in our production clusters, but what's the overhead on a single user machine?
- Meph504 7y ago
  I do mean elastic search, and the hardest part is automating the installer, integrating the providers for all the file types you want, and building the first index,in a passive manor. But once you do that the overhead isnt horrible, you do the indexing on change, and results comeback as fast as a typical small query, 10 seconds tops on a typical desktop machine. We wrote a scheduler that on windows monitored the windows indexer itself, when it kicked off we scheduled it, and trigged it once the system finished. I don't honestly recommend it over windows search, but if portability, and multi system searching is required it worked great. But not a task for those who are crunched for time, or lack resolve.

jjoonathan 7y ago

If the backend of Windows Search is amazing, why is the front-end user experience abysmal? The problems just don't seem like front end problems: the search is occasionally slow, it doesn't even reliably find installed programs by their name, and if the result pops up while your next keystroke is underway it will sometimes lose the result even if that keystroke is correct, and somehow finding the result again will require removing more than the single correct keystroke that made your desired result disappear. The mind boggles. I'm not familiar with Windows internals, so I should clarify: I'm talking about the search functionality invoked by typing after pressing the Windows key. If I were an app developer in this space I would not trust my core functionality to anything even remotely associated with the above, and I strongly suspect that the complexity of handling the long tail of functionality you mentioned has something to do with why the windows-key search experience sucks. Certainly the fundamental task is not intractable because Spotlight (Apple's search) has been Good Enough for a while. IIRC it became tolerable around the time SSDs became standard. Windows-key search isn't quite there yet. Until it is, I'll take good execution on the basic 80% of functionality any day.

Meph504 7y ago
The front end is a mystery to me, windows search backend is a queryable system, it's reliable, impressively fast, and suffers from none of the issues that have plagued not only the win10 search, but windows explorer as well. I've never understood why it's performance has been deemed acceptable. I'm on my phone right now so forgive the random sample, but this gives the gist of its usage. https://stackoverflow.com/a/34340288 https://stackoverflow.com/a/34340288 The only issue I have seen is when the index corrupts, this was more common in win7, and in our research it was often the result from an over aggressive AV jamming up the process. But I've written a number of systems that make use of this, and when comparing other ways to accomplish this sort of in depth search, it's the most reliable and manageable. It does have the caveat that it works best on places indexed by the OS, and adding locations to the indexer via code requires some pinvoke stuff most people aren't comfortable with.
buckminster 7y ago
There seems to be more than one index. There is the index of scanned file content, an index for apps, and maybe another one for help. There is also a query timeout. If you start searching after a boot on a slow laptop you get a subset of results dependent on which index is loaded before the query times out. Kill the start menu and try again. And again. And then it works smoothly. It's quite poor.

EdwardDiego 7y ago

Wait, by Elastic, do you mean Elasticsearch? Genuinely curious, as I've only ever used it for large scale log ingestion/APM etc. in our production clusters, but what's the overhead on a single user machine?

Meph504 7y ago
I do mean elastic search, and the hardest part is automating the installer, integrating the providers for all the file types you want, and building the first index,in a passive manor. But once you do that the overhead isnt horrible, you do the indexing on change, and results comeback as fast as a typical small query, 10 seconds tops on a typical desktop machine. We wrote a scheduler that on windows monitored the windows indexer itself, when it kicked off we scheduled it, and trigged it once the system finished. I don't honestly recommend it over windows search, but if portability, and multi system searching is required it worked great. But not a task for those who are crunched for time, or lack resolve.