3 ms·
It’s relatively easy to implement search - you need only minimize the Levenshtein distance between the search string and the file name string. The difficult par
by 0x8BADF00D 7y ago
It’s relatively easy to implement search - you need only minimize the Levenshtein distance between the search string and the file name string. The difficult part is actually indexing all file names and their string contents on the system. Grep is a different tool, mainly using regular expressions to match strings within files and I don’t think it is feasible to be continually loading the contents of all strings contained in all files into memory to perform fuzzy string matching.
- badsectoracula 7y agoI was always very skeptical about the need for search indexing for local files - how often do you search for stuff to need indexing in the first place? I have a ton of files, certainly more than the average Windows user and i do search for things often enough (at least once a day). To search i use Total Commander (allows for both wildcard/regex searches, archive searches, content search with a bunch of options) which doesn't use indexing at all and search speed was never something i had as a problem (and in general i hate waiting for the computer to do stuff). In what workflows is search needed so often and for so many files that it necessitates indexing? Even back when i first encountered it (in Vista - AFAIK it existed in XP and before but it wasn't enabled by default) i thought it was a waste of resources and unnecessary complexity.
- ptidhomme 7y agoTotally agree. Back then in XP I'd always disable search indexing, prefetch and superfetch in order to reduce that constant disk activity.
- mlang23 7y agoAgreed. updatedb from the locate package is typically the first thing that I uninstall on a new Linux installation. The nightly cronjob definitely consumes a lot more resources over time then it will ever save me waiting time.
- tjoff 7y agoEvery time? Searching everything takes lots of time, searching through an indexed database takes less than a second. When in windows I use a locate-port[1] that I use to index any local disks as well as remote network shares of interest. It would take about an hour to search everything. But an hour wouldn't be that bad, the problem arises when you are not quite sure what you are looking for. Getting the response back instantaneous is invaluable because you can refine your search in seconds. [1] https://locate32.cogit.net/ https://locate32.cogit.net/
- caspper69 7y agoAnd your use case makes sense; but your use case is not typical for 99% of desktop OS users. And instantaneous results mean nothing if they're worthless. I'd rather let you turn on indexing because you need it and it matches your use case. Leave the other 99% alone.
- tjoff 7y agoIndexing benefits the other 99% as well. Windows default was ok but slow in XP and absolutely unusable since. Any benefit to search would be a massive benefit to millions of people. Doesn't have to be indexed but would certainly help. I guess SSDs are quick enough many times but it is absolutely essential if a regular hard drive is in the picture.
- mintplant 7y agoI use Everything [0], a similar program which is designed to stay resident and essentially become part of your keyboard muscle memory. I have a couple custom shortcuts configured so I can easily open the result, open the result and hide the Everything dialog, or open the folder containing the result. [0] https://www.voidtools.com/support/everything/ https://www.voidtools.com/support/everything/
- numpad0 7y ago> The difficult part is actually indexing all file names okay, ... > and their string contents on the system ... why would you even do that? ls-lR.gz works. And that’s exactly what people wants 80% of time.