Why is Everybody so clueless on the importance of Desktop Search to the Masses?
-
@SpectateSwamp said:
This forum is just getting too long for other searches to bring up quick results
Google has already done the work for you. Don't have to make large index file. Just type in Google. Google filters by site without copy/paste.
There are nine posts in this thread that use the word "performance." Find them all. Go!
[img]http://img135.imageshack.us/img135/8350/threadsearchev9.png[/img]
Done.
-
@GalacticCowboy said:
There are nine posts in this thread that use the word "performance." Find them all. Go!
Crap, now there are ten. Or eleven.
-
Or 62... :) when I push the "Include omitted results" link... Congratulations, self, you are your own TRWTF.
-
@SpectateSwamp said:
So That is where the next set of video is going. SSDS internals explained. I'll go through the code at the important points. Where and how changes can be made.
Or you could document and clean up the source so it is understandable. @SpectateSwamp said:
I might even go over the changes required to make SSDS do a LIVE search of text files. (fiddle with the merge option to redirect the merge info to the logic where SSDS reads from the input file)
Will this include handling multiple folders?
@SpectateSwamp said:
When you got spaghetti code. You'll need a little help
A lot. Of help.
-
@SpectateSwamp said:
So That is where the next set of video is going. SSDS internals explained. I'll go through the code at the important points. Where and how changes can be made. I might even go over the changes required to make SSDS do a LIVE search of text files. (fiddle with the merge option to redirect the merge info to the logic where SSDS reads from the input file) It will be slower but that is what people here are screaming for. All on shaky shaky video. Sit close to your monitor for these lessons. When you got spaghetti code. You'll need a little help
But nobody wants to make those changes for you. As far as I can tell, nobody here wants to use your application and nobody wants to help you improve it. There are already plenty of ways to do non-indexed search of text files besides SSDS. Most of them search through multiple files and directories: jEdit (hypersearch), grep, Microsoft Visual Studio, Windows Search (non-indexed), "find" (Windows command line equivalent of grep; works with Unicode), etc.
And most applications already have a nice interface for searching their own data: e.g. EverNote, Outlook Express, Adobe Acrobat Reader, Thunderbird (mail client), etc.
Why do we need SSDS again?
-
@CodeSimian said:
And explain to me why I wouldn't just use a program like EverNote to organize and search my plain text and web notes. Explain why people pay money to use EverNote but nobody cares about SSDS?
Thanks for pointing that one out. I'd never seen it before. I'm giving the free version a go. If it turns out to be good, I'll register it (50% discount currently in effect).
-
EPIC THREAD!!
Full of EPIC FAIL
-
Few demos from the Indexers - Nothing to show I guess.
@spenk said:
Will this include handling multiple folders?
A list of folders would be cool. Just skip that directory. If it doesn't match one on the list. Currently the program will "merge" all files on c: or c:\search\ etc but a list of selected folders wouldn't be hard to add. I'll probably just do the c:\ or c:\search\ searches first. Might start with an even simpler fix/change. Control.txt element 31 is the hilite_this element. If a match is found in any of the context lines it is hilited in a different color (cmd(29) has the color). It is not searched for or hilited if it is in the match line. How best to fix this minor problem? I'll make the changes before explaining it. None of the other searches have a hilite_this element. One can use the hilite_this element to hide certain words. By setting the hilite color in 29 to MATCH the background color in control element #3 With both cmd(3) and cmd(29) being set to 3 (aqua) any hilite_this strings would appear as blank spaces in the middle of the text. SSDS is a tool to plow through your data. Not just slowly presenting 1 file match at a time.
Another test. 100 matches in 100 files somewhere on c drive and in text. Who would have them up on the screen the fastest. Indexing and merging times included. SSDS presents the text in context. It would be just a matter of hitting enter 100 times after the merge was done. Like in 5 minutes I would be done done done. You would have to tell your indexers which folders to ignore or it would be days and days later. Indexers tell you what files your search string is in. Pick a common one and the list is overwhelming. SSDS will show the matches in context or matching lines only for even faster verification. Indexing searches suck and the showdown will hilite these and other glaring weaknesses.
Search is about the context. Not the file name where the context is. The indexers will show your a few lines from the beginning of the match file and if the string is there hilite it. It can't look any farther otherwise it would slow tremendously.
-
@SpectateSwamp said:
Search is about the context. Not the file name where the context is. The indexers will show your a few lines from the beginning of the match file and if the string is there hilite it. It can't look any farther otherwise it would slow tremendously.
Fine, you want to search text files with context, highlighting, and the ability to press a key (or click a button) to jump to the next match? Here you go - Notepad++:
If I wanted to, I could copy and paste all 30+ pages of this thread into a plain text file and use Notepad++ to search it. Notepad++ is more powerful, easier to use and doesn't require any keyboard commands or shortcuts. Explain to me why I should use SSDS instead of Notepad++ to do your kind of searching.
Nobody needs your product because there are a million more useful and simpler alternatives.
-
The Grepplers VS the Itsy-Bitsies
@CodeSimian said:
Explain to me why I should use SSDS instead of Notepad++ to do your kind of searching.
Reasons for SSDS? Random. Large font scrolling text. Pause then continue on a page full. HiLite_this element. Masking characters with aqua in cmd(29). I had just reloaded the most recent forum posts. Including the note on aqua. Extracts are a useful (part of the extract-sort-report trio) Multiple sessions of this search with the defaults and search history that apply to that topic or project. 8 or 20 data files instead of TENS of Thousands. Now to me, when documents never get printed again And I Can't scan them in context because I have an indexer. One will seldom looks at files, if it is a problem moving to the next file then the next match in that file search again don't find a match go to the next itsy bitsy file. You won't do that long before you quit searching. For me it's enter search string and enter enter enter everything in context and extremely fast. more than extremely fast even.
-
@SpectateSwamp said:
A list of folders would be cool. Just skip that directory. If it doesn't match one on the list. Currently the program will "merge" all files on c: or c:\search\ etc but a list of selected folders wouldn't be hard to add. I'll probably just do the c:\ or c:\search\ searches first. Might start with an even simpler fix/change.
Not just a list of one or two folders but entire directory trees.
@SpectateSwamp said:
Another test. 100 matches in 100 files somewhere on c drive and in text. Who would have them up on the screen the fastest. Indexing and merging times included. SSDS presents the text in context. It would be just a matter of hitting enter 100 times after the merge was done. Like in 5 minutes I would be done done done. You would have to tell your indexers which folders to ignore or it would be days and days later. Indexers tell you what files your search string is in. Pick a common one and the list is overwhelming. SSDS will show the matches in context or matching lines only for even faster verification. Indexing searches suck and the showdown will hilite these and other glaring weaknesses.
Given you currently only support searching one file at a time the claim of a 100 matches in a100 files is nonsense, WDS will happily find search terms in the 36,000+ items I have with virtually no delay whatsoever.
Why would I be waiting days if I didn't ignore folders with an automatic index based search (as opposed to your manual index process) - 36,000 items isn't more than a handfull of hours and it happens quietly in the background without my time being wasted manually merging files...
SSDS shows you the file your search string is in - it is in the file you told it to search. How would it help you to locate the file file(s) that contained the search string?
What on earth does 'show the matches in context' actually mean anyway?
As to claiming index based searches suck you are missing two vital points - one is many years of development and study have proved that index based searching is quicker and secondly you use an index based search anyway, the only difference is you require the user to build the index themselves, file by file by file.
-
@SpectateSwamp said:
@CodeSimian said:
Explain to me why I should use SSDS instead of Notepad++ to do your kind of searching.
Reasons for SSDS?<snip>
8 or 20 data files instead of TENS of Thousands.
</snip>
You have it all backwards. SSDS doesn't allow me to have 8 or 20 data files instead of thousands - SSDS forces me to merge all my data into 8 or 20 files. It's not a feature, it's an onerous requirement.
For the millionth time, NOBODY WANTS TO MERGE ALL THEIR FILES TOGETHER and no other search program forces them to.
-
@SpectateSwamp said:
Masking characters with aqua in cmd(29).
So it finds the search term in the specified file but then doesn't display it???
@SpectateSwamp said:
8 or 20 data files instead of TENS of Thousands.
You are forcing me to only have 8 or 20 files regardless of how I want to work. How can I maintain my source code as 8 or 20 files?
@SpectateSwamp said:
And I Can't scan them in context because I have an indexer. One will seldom looks at files, if it is a problem moving to the next file then the next match in that file search again don't find a match go to the next itsy bitsy file. You won't do that long before you quit searching. For me it's enter search string and enter enter enter everything in context and extremely fast. more than extremely fast even.
Most of that doesn't even make sense. What on earth does scan them in context mean? How can finding the term in the original file be out of context? It isn't a problem moving to the next file either - you just double click on it. Who cares if the file is small, I have source files that just define an interface that may be only one or two kilobytes - that however allows me to organise my source files as I choose to. I would have no benefit merging these into one large file.
-
SSDS feature Rich
I forgot to mention SSDS doesn't choke or slow down on larger files. ie 2m to over 1Gig. The Itsy-bitsies don't keep lots of clippings in one file. They have to split up on a one per article basic. Their indexing search is just too slow displaying files of any size. Probably by now copernic will take 25 seconds to get a match at the end of this forum up and in context. Try this number Mr Copernic 388205283 The wonderful SSDS search will show it to you in less than a second. Others can verify this quite easily. Does nobody want to try it? Maybe SSDS is even faster and Copernic worse than expected. Do I have to do another video. Another feature is instant search default changes at prompt #2 'ccc' uses the settings in control1.txt instead of control.txt.
When Desktop Search is your only program, It has to have all the options this one has.
-
@SpectateSwamp said:
I forgot to mention SSDS doesn't choke or slow down on larger files. ie 2m to over 1Gig.
Then explain http://forums.thedailywtf.com/forums/p/7593/144805.aspx#144805
@SpectateSwamp said:
The Itsy-bitsies don't keep lots of clippings in one file. They have to split up on a one per article basic.
Could you please try to manages sentences - they make reader comprehension so much easier, but what the fuck does 'The Itsy-bitsies' mean? What or who is having to split up on a one per article basis? What does that even mean?
@SpectateSwamp said:
Their indexing search is just too slow displaying files of any size. Probably by now copernic will take 25 seconds to get a match at the end of this forum up and in context. Try this number Mr Copernic 388205283 The wonderful SSDS search will show it to you in less than a second. Others can verify this quite easily.
You still haven't proved this without cheating, if you are benchmarking SSDS we need to see you do it from a cold boot and without you pre-reading the file in.
@SpectateSwamp said:
When Desktop Search is your only program, It has to have all the options this one has.
For most people desktop search isn't their only program, it is the program they use to search for files. It isn't even your only program as you rely on media player for your mp3 and video playback.
-
Grepplers would win any Desktop Search ShowDown
@spenk said:
I would have no benefit merging these into one large file.
Come on SpenkSwamp do it just to humor me. Merge all your source files (but don't delete the originals) SSDS has no feature to delete merged files. Then start looking for anything that pops into your mind code wise. Let the whole mess flash by, by using the "f" for flash mode at prompt #2. The search will show all text on the screen until a match is found. Enter a number that doesn't exist in the file and all your source code will flash by. Stop and restart it by hitting enter. Play with and examine your source like never before. How many meg of combined source. How many lines of info. What is the elapsed time for a 'y' showing the last screen full of text.
@spenk said:
And I Can't scan them in context because I have an indexer
I should have used view instead of "scan" ie "scan them visually in context because indexers can't do that at an acceptable speed. They just can't. Swamp search can.
-
@SpectateSwamp said:
Come on SpenkSwamp do it just to humor me. Merge all your source files (but don't delete the originals) SSDS has no feature to delete merged files. Then start looking for anything that pops into your mind code wise. Let the whole mess flash by, by using the "f" for flash mode at prompt #2. The search will show all text on the screen until a match is found. Enter a number that doesn't exist in the file and all your source code will flash by. Stop and restart it by hitting enter. Play with and examine your source like never before. How many meg of combined source. How many lines of info. What is the elapsed time for a 'y' showing the last screen full of text.
But why? I can happily search my code now without having to merge hundreds of files into one just to watch code flash by. So watching code flash past is examining my code? Admittedly I have never done that before, probably due to the fact I have tools that can do analysis of my code, display meterics about my code, refactor my code, allow me to skip back and fore between declarations and calls. I can even compile it!
What benefit does having two copies one of which is merged into a useless large file give me?
-
@SpectateSwamp said:
Enter a number that doesn't exist in the file and all your source code will flash by.
HAHAHAHA so it is going to make you display the whole file even when it doesn't find anything??
Brilliant! Spectate, you seem to be getting dumber by the post...
-
Not so Fastest (Copernic)
@spenk said:
you rely on media player for your mp3 and video playback.
I see no calls to media player in the source code. I see mcisendstring commands that control the video and music. Any OS worth it's salt would have a similar utility.
http://www.telusplanet.net/public/stonedan/source.txt
@spenk said:
if you are benchmarking SSDS we need to see you do it from a cold boot and without you pre-reading the file in.
Can't anybody else take a stab at searching thedailyWTF.txt text file for this thread? I know you can all whip up a batch file that will merge this and that, yappity yap. Just go in and cut and paste 31 times and it will be done. Then do some simple testing to see who can display the data the fastest (SSDS) and Not so fastest (Copernic)
-
@SpectateSwamp said:
I see no calls to media player in the source code. I see mcisendstring commands that control the video and music. Any OS worth it's salt would have a similar utility.
Do you think MCISendString is invoking some kind of magic?
@SpectateSwamp said:
Can't anybody else take a stab at searching thedailyWTF.txt text file for this thread? I know you can all whip up a batch file that will merge this and that, yappity yap. Just go in and cut and paste 31 times and it will be done. Then do some simple testing to see who can display the data the fastest (SSDS) and Not so fastest (Copernic)
Nobody here is stupid enough to do this except you. The rest of us have at least the minimal intelligence level to be able to type what we want in the search box and press enter. You can never claim to be faster than that.
Did you do a lot of drugs in your younger years?
-
@SpectateSwamp said:
@spenk said:
if you are benchmarking SSDS we need to see you do it from a cold boot and without you pre-reading the file in.
Can't anybody else take a stab at searching thedailyWTF.txt text file for this thread? I know you can all whip up a batch file that will merge this and that, yappity yap. Just go in and cut and paste 31 times and it will be done. Then do some simple testing to see who can display the data the fastest (SSDS) and Not so fastest (Copernic)You are losing it here - you are claiming to out perform copernic with ssds but stacking the deck in your favour and not running a fair test. What this has to do with cut and pasting this forum is beyond me.f you are trying to find the post in question, rather than cut and paste I shall use the forums own search box, don't go away...
...and I'm back http://forums.thedailywtf.com/forums/p/7593/147518.aspx#147518 was the link. Your had pre-loaded / pre-configured ssds so it didn't need to open the file and perform a full search. That is not a fair benchmark and no sane person would treat it as one.
-
SSDS replaces oodles of Geek tools.
@spenk said:
due to the fact I have tools that can do analysis of my code, display meterics about my code
If I added up all the tools you people have for doing this and that function better than SSDS. It would be quite a list. Thankfully Swamp search is the tool to search out such info. Very fast to move through mountains of Search Facts like this post.
SpenkSwamp do us a demo using Cam Studio and settings like I used. So everything is blurry. We'll trust you. Your source code should be your secret. Then a few simple searches on that merged file looking for subroutine calls, error handling, what ever. You will move through your source very fast. How many lines of code do you have? Not nearly enough to cause Swamp search to even pause. I bet.
-
@SpectateSwamp said:
If I added up all the tools you people have for doing this and that function better than SSDS. It would be quite a list. Thankfully Swamp search is the tool to search out such info. Very fast to move through mountains of Search Facts like this post.
Most of the things I mentioned are part of Visual Studio, so not a lot of tools. Searching I use WDS which is built in to Vista, for source code control I use tortoise svn and subversion - not a great many tools.
@SpectateSwamp said:
Then a few simple searches on that merged file looking for subroutine calls, error handling, what ever. You will move through your source very fast. How many lines of code do you have? Not nearly enough to cause Swamp search to even pause. I bet.
I am not going to merge my source files! There is no point and no benefit. The size of the source isn't a problem it is simply the fact /i cannot be arsed merging all the files from several subfolders just to use your sub standard single file searching tool. Show me how SSDS can locate a function declaration as opposed to a call to the same function easily (holding enter till I spot the correct entry isn't a valid option).
If you are so convinced your way is best try the challenge I set - download the less than 6M subversion source, extract the files to the normal directory structure and video yourself doing the merge. Show us how quick and easy it is and how fast your results are.
-
@SpectateSwamp said:
@CodeSimian said:
Explain to me why I should use SSDS instead of Notepad++ to do your kind of searching.
Reasons for SSDS? Random.I don't want this.
@SpectateSwamp said:
Large font scrolling text.
I don't want this, either.
@SpectateSwamp said:
Pause then continue on a page full.
GDS does this better.
@SpectateSwamp said:
HiLite_this element.
GDS does this better, too.
@SpectateSwamp said:
Extracts are a useful (part of the extract-sort-report trio)
A lot of my day job involves writing reports. If I tried to write them using SSDS, then I would be fired, and rightly so. SSDS is about as good at producing reports as MySpace is at producing pleasing color combinations, namely not at all.
@SpectateSwamp said:
For me it's enter search string and enter enter enter everything in context
It's Boomhauer! "Yeah man, I tell ya what, man, that dang ol’ internet, man, you just go in on there and point and click, talk about w-w-dot-w-com, mean you got nekkid chicks on there, man, just go click, click, click, click, click, it’s real easy, man."
For GDS it's enter search string and everything in context without having to keep hitting enter.
-
@aleph said:
@tdittmar said:
So if you want to do a real comparison: reboot your machine, search with Copernic and write down the time it took. Then reboot your machine again, write down start time, start SSDS, open file, search term, write down end time. THAT gives us the real numbers.
I second (or third, or whatever we're up to) this motion.
Swamp, please make a video of the above instructions. We might actually take the video seriously if you do a proper clean test like the above.
Swamp, either do this- a FAIR comparison- or shut the hell up about being "faster" than Copernic.
What you're doing now is like me challenging you to a race to my house, to prove I can run faster than you. I'm IN my house, you're in a trailer in Canada, and unless we both start in the same place it proves nothing.
-
@SpectateSwamp said:
@spenk said:
I would have no benefit merging these into one large file.
Come on SpenkSwamp do it just to humor me. Merge all your source files (but don't delete the originals) SSDS has no feature to delete merged files.
@SpectateSwamp said:
Can't anybody else take a stab at searching thedailyWTF.txt text file for this thread? I know you can all whip up a batch file that will merge this and that, yappity yap. Just go in and cut and paste 31 times and it will be done. Then do some simple testing to see who can display the data the fastest (SSDS) and Not so fastest (Copernic)
NOBODY WANTS TO MERGE ALL THEIR DATA INTO A SINGLE FILE!!! NOBODY WANTS TO COPY AND PASTE THEIR RICH DATA FORMATS INTO PLAIN TEXT!!!
Is that really so hard for you to understand? I want to keep my data in separate files, in their original format (.PDF, HTML, etc.). If I want to search plain text files, I already have plenty of tools that do it way better than SSDS.
When Ford designs a new 4x4, do you think they tell their customers what they need in a truck? No, they try to figure what their customers want, and give it to them.
Google doesn't try to tell people how to search; it gives people a way to search the Internet and their desktop that's convenient for the people.
Let's see, what would be easier? Millions of computer users changing their workflow to suit your application's needs, or you changing your application so it does what millions of users WANT?
And I already use grep, so why do you seem to think I need to use SSDS to be a "greppler"?
As an example of why nobody wants to copy and paste all their data into plain text: this forum thread contains hyperlinks, formatting and images that will be lost if you copy and paste it as plain text. Is that so hard for you to understand?
And for the millionth time, even if you could somehow convince every last forum member that SSDS is superior, what do you think WE can do about it? There is NOTHING we can do to help SSDS take over the world. NOTHING.
Why don't you submit your ideas to Google, Microsoft, or the patent office?
-
If SpectateSwamp designed the Internet...
...instead of millions of web sites, there would only be "8 or 20". Each site would be a single page of about 10 million lines of plain text with no images, hyperlinks, video, or formatting, all the better to search through.
Spectate, would you rather use an Internet with 8 sites of a million lines each, or millions of sites with a manageable number of lines each?
If you can answer that question, then you also know why we don't want to merge all our data into a handful of plain text files.
-
SSDS fails at random!
@SpectateSwamp said:
Reasons for SSDS? Random.
You mean this random?
http://www.mediafire.com/?cbn3vyy0hdd
Boy, that sure is useful!
I followed your directions: http://forums.thedailywtf.com/forums/p/7593/144098.aspx#144098
Sorry, SSDS has failed to even perform the useless tasks you advocate.
(note: Watch the title bar for extra fun. Also, notice you cannot exit from the continue box. Ok, cancel, y/n, nothing works. Task Manager is needed. )
Look Ma! No camcorder needed! Wow!
-
10,000 Swamp Searches could run the Internet...
@CodeSimian said:
I like the way you use the Subject. 8 or 20 huge files searched by 10,000 backgrounder Swamp searches. Damn it. that would work and the speed....instead of millions of web sites, there would only be "8 or 20". Each site would be a single page of about 10 million lines of plain text with no images, hyperlinks, video, or formatting, all the better to search through.
Spectate, would you rather use an Internet with 8 sites of a million lines each, or millions of sites with a manageable number of lines each?
If you can answer that question, then you also know why we don't want to merge all our data into a handful of plain text files.
-
@SpectateSwamp said:
10,000 backgrounder Swamp searches.
Too bad there is nothing even close to a background thread in your 'search'.
Of course, why should that matter? Your 'search' doesn't search anything either.
-
@SpectateSwamp said:
@CodeSimian said:
I like the way you use the Subject. 8 or 20 huge files searched by 10,000 backgrounder Swamp searches. Damn it. that would work and the speed....instead of millions of web sites, there would only be "8 or 20". Each site would be a single page of about 10 million lines of plain text with no images, hyperlinks, video, or formatting, all the better to search through.
Spectate, would you rather use an Internet with 8 sites of a million lines each, or millions of sites with a manageable number of lines each?
If you can answer that question, then you also know why we don't want to merge all our data into a handful of plain text files.
Let me get this straight. You are saying that you would use the Internet if it consisted of only 20 pages of several million lines each? And you think normal human beings would find it useful?
You still didn't answer my question: what do you hope to achieve on this forum?
-
@CodeSimian said:
Let me get this straight. You are saying that you would use the Internet if it consisted of only 20 pages of several million lines each? And you think normal human beings would find it useful?
You'd have to admit having only 8 pages for the entire internet would make searching it alot easier.
I'm curious though, does SSDS allow for full-triplex mega-sorting? I'm looking for something that granulates my meta data into a relation rotation alpha-based key table, if it has beta-key encryption that would be even better. Also while on the note of looking for obscure programs I'm looking for an AJAX implementation of a semi-autonomous reversible archive with functional neural-net compiler complete with a non-intrusive scaling capabilities and a self-generating intuitiveness interface.
-
@SpectateSwamp said:
The wonderful SSDS search will show it to you in less than a second.
No, the "wonderful" SSDS will probably take 1 minute and 25 seconds, which is 5 times longer than Copernic.
<font size="3">You are still providing wrong numbers, helloooo! </font>
-
@emurphy said:
@SpectateSwamp said:
For me it's enter search string and enter enter enter everything in context
It's Boomhauer! "Yeah man, I tell ya what, man, that dang ol’ internet, man, you just go in on there and point and click, talk about w-w-dot-w-com, mean you got nekkid chicks on there, man, just go click, click, click, click, click, it’s real easy, man."
Believe it or not, he talks like that in real life, too:
SpectateSwamp: Thank you Doug and Pete (?), and the fine, fine people of Yellowhead, Yellowhead, Yellowhead.
[Audience laughs]
Random Audience Member: We get it.
By the way, if anyone wants to write up a full audio transcript of Swamp's little political speech, that would be awesome. I'd do it myself, but I can only make out about 90% of what he's saying - either the audio quality sucks or I'm going deaf.
-
@SpectateSwamp said:
I forgot to mention SSDS doesn't choke or slow down on larger files. ie 2m to over 1Gig.
NOBODY uses a 1GB text file. Not even a 2MB one, because it's just unusable. So nobody cares about being able to search fast in them.
With a 1GB file you WILL need a search tool to find something in it as it's just so big you can't see a thing. But if you have multiple small files, with a nice filename (you know, that short string that allows you for example to describe the file's contents), you'll instantly see in which small file what you need is in. Open it, and voila you don't even need a search program to find what you need in it.
But your mind is too broken to understand the concept of files, why they exist and how to organise them anyway. I hardly ever need to search inside files. If I need to search for something, it might be the filename. And that's even rare as I know where the file that holds what I want is, or I can find it out following my directory structure, faster than any search tool. Especially that none yet will be able to find me a picture or video if I give it "the one that has a red bridge in it" as a search string. And even then, even with an index it might be slow to go through 250000 files totalling 500GB.
About merging an entire code project into one file, you said it was easy to do, OK. It's useless, we all know. But let's assume a few seconds (longer will start hurting too badly) it would be a sensible option, now you have a single file you can search with SSDS. You type your keyword, and find a match. Cool. That's not the one you want. You press enter 200 times to reach the good one, how cool. Now a usual purpose to searching for something is to edit it. But... editing the merged file is useless. So what do we have to do now? As SSDS won't even tell you what file the original tesxt is, you... have to run a search again with a normal search tool to find the file and text again. Cool huh? Now SSDS is a really useful application.
Not to mention your "context search", when you actually are destroying the context with the merging. A search for a keyword with a normal and usable tool will give me 10 file results. By the filename, that can be interpreted as context, I will know in which one of them the actual appearance of the keyword that interests me is. I can then open this one and find it. No need for countless Enters that nobody wants to do.
Maybe you didn't clarify the fact that SSDS is a tool that allows you to search just to search for something without actually wanting to do anything with it. Maybe there it would have a use. "Oh I'm bored today, what shall I do? Let's search for something. OK, found. Now let's search for something else."
-
SSDS ftw
What is everyone complaining about? SSDS is the only desktop search engine I know of that can RANDOMLY play back all of my VIDEOS in 2sec segments (with pause and resume functionality no less), have RANDOM, LARGE FONT text messages zooming across the screen at UNBELIEVABLE speeds (surely too fast to be true!), can display QUESTIONS in a THOUGHT PROVOKING way ("Why oh why did I install this?"), and MERGE all my text files into one large file which, I may add, is so much faster to BACKUP than 1000s of little files (that I don't really need) that would take much longer to copy than ONE LARGE FILE.
Whatever else SSDS may be, it's the best in its class.
-
SSDS 30 time Faster than Copernic
@Kilrah said:
NOBODY uses a 1GB text file. Not even a 2MB one, because it's just unusable. So nobody cares about being able to search fast in them.
This thread is now at 1,852,065 characters long and 49,703 lines (some very long) I tested the Copernic preview of the search for "388205283" the total time before the CONTEXT showed up is now up to 26 Seconds. SSDS context search shows results in .735 seconds and the 's' search produced results in .125 seconds. So for files around the 2Mb size Copernic is virtually useless. 26 seconds is way to long to have to wait to see the context. All Copernic would need to do to FIX this problem would be to put a SSDS call right at the preview stage, instead of notepad or wordpad or whatever they currently use.
Seems nobody is even coming close to reproducing my test results, rambling on about SSDS times of a minute and 20 seconds or so. Obviously nobody has tried this simple test. I will post a screen captures of the copernic results and keep updating it as TIME passes. The results will have my x on it. Certifying it official.
-
ShowDown Show Stoppers - Poor Copernic
These would be show stoppers in any showdown. Copernic preview times on this thread being so slow. And no warning about large file sizes and indexing problems. Don't let your Desktop Search limit your search options.
http://www.telusplanet.net/public/stonedan/copernic_test01.jpg
-
@joe17301 said:
What is everyone complaining about? SSDS is the only desktop search engine I know of that can RANDOMLY play back all of my VIDEOS in 2sec segments
Actually, it cannot even do that: http://www.mediafire.com/?cbn3vyy0hdd
-
@MasterPlanSoftware said:
@joe17301 said:
What is everyone complaining about? SSDS is the only desktop search engine I know of that can RANDOMLY play back all of my VIDEOS in 2sec segments
Actually, it cannot even do that: http://www.mediafire.com/?cbn3vyy0hdd
Hmmm... it's video, so I can accept this as fact. I hereby declare mysef proven wrong.
And another thing...
SpectateSwamp: Redrawing the second hand in red (meaning you edited the image) is not the same as showing a direct comparison, from the beginning, of the power of SSDS vs Copernic. But nice try though. I think one of the users here is a 12-year-old-girl and she was almost fooled.
-
SSDS is all about Video
@MasterPlanSoftware said:
JoeSwamp is right. Mess with the catalog file a bit and do even more strange displays. Ie add freeze frame to them all. Set it to slow motion for even more video entertainment.@joe17301 said:
What is everyone complaining about? SSDS is the only desktop search engine I know of that can RANDOMLY play back all of my VIDEOS in 2sec segments
Actually, it cannot even do that: http://www.mediafire.com/?cbn3vyy0hdd
-
@SpectateSwamp said:
Mess with the catalog file a bit and do even more strange displays. Ie add freeze frame to them all. Set it to slow motion for even more video entertainment.
So then you know that SSDS is broken and doesn't even do what you claim it does?
-
@SpectateSwamp said:
JoeSwamp is right. Mess with the catalog file a bit and do even more strange displays. Ie add freeze frame to them all. Set it to slow motion for even more video entertainment.
Oh great... and here I thought unscrewing the casing of my MFM HDD and opening it to hear a disturbing tearing sound was my finest moment in computing.
But no, it turns out it gets better. JoeSwamp.
I have no better way to end this than Yellowhead, Yellowhead, Yellowhead.
-
Where are the Search Giants?
@MasterPlanSoftware said:
So then you know that SSDS is broken and doesn't even do what you claim it does?
Enough questions. Where are the Search Giants? How come they haven't shown up here yet. Do I have to do their testing and demos. Why is that preview screen so terribly slow? Does anybody here try anything or just sit and babble. The last search Giants were Old Greppler himself and the Vax/Dec search program developers. Maybe one or two of them would put in a comment or two here. If they dare.
-
@joe17301 said:
Oh great... and here I thought unscrewing the casing of my MFM HDD and opening it to hear a disturbing tearing sound was my finest moment in computing.
But no, it turns out it gets better. JoeSwamp.
Sorry...
I feel dirty...
-
@SpectateSwamp said:
@MasterPlanSoftware said:
So then you know that SSDS is broken and doesn't even do what you claim it does?
Enough questions. Where are the Search Giants? How come they haven't shown up here yet. Do I have to do their testing and demos. Why is that preview screen so terribly slow? Does anybody here try anything or just sit and babble. The last search Giants were Old Greppler himself and the Vax/Dec search program developers. Maybe one or two of them would put in a comment or two here. If they dare.
So you wont answer the video that shows SSDS not working at all?
Everything you have made work in SSDS has been a lie. Sorry, you fail.
Game over.
-
@SpectateSwamp said:
@MasterPlanSoftware said:
So then you know that SSDS is broken and doesn't even do what you claim it does?
Enough questions. Where are the Search Giants? How come they haven't shown up here yet. Do I have to do their testing and demos. Why is that preview screen so terribly slow? Does anybody here try anything or just sit and babble. The last search Giants were Old Greppler himself and the Vax/Dec search program developers. Maybe one or two of them would put in a comment or two here. If they dare.
Oho I like that Swamparoonie. "If they dare". Mighty, powerful words. Why don't you ask them instead of hanging around on forums bothering us? Have you tried contacting them?
Do you know how to?
-
@SpectateSwamp said:
I tested the Copernic preview of the search for "388205283" the total time before the CONTEXT showed up is now up to 26 Seconds. SSDS context search shows results in .735 seconds and the 's' search produced results in .125 seconds.
This is lunacy! This is madness!
THIS IS SSDS!!!
Seriously though, these numbers are NOT valid. As I've said many many times, the numbers will only mean ANYTHING if you:
1. Reboot your machine.
2. Start timing.
3. Search for the text using Copernic.
4. Stop timing.
5. Write down the time.
6. Reboot your machine again.
7. Start timing.
8. Search for the text using SSDS.
9. Stop timing.
10. Write down the time.
11. Compare the two times.
If you don't do BOTH searches first thing after a clean boot, then your results are NOT valid. Like I said, it's like you VS me in a race to somewhere that's near me...
ALSO, what the fuck do you mean by "context"? The SSDS results are NOT in context, as they're in a merged text file copy of the forum, not the actual forum!
-
@rc_pinchey said:
ALSO, what the fuck do you mean by "context"? The SSDS results are NOT in context, as they're in a merged text file copy of the forum, not the actual forum!
Kind of like how his prized 'random' functionality doesn't even work? I mean Jesus how easy would it be to write a quick VB program that would autocatalog and randomly play your videos... and he FAILED! OMFG!
-
@SpectateSwamp said:
@Kilrah said:
NOBODY uses a 1GB text file. Not even a 2MB one, because it's just unusable. So nobody cares about being able to search fast in them.
This thread is now at 1,852,065 characters long and 49,703 lines (some very long) I tested the Copernic preview of the search for "388205283" the total time before the CONTEXT showed up is now up to 26 Seconds. SSDS context search shows results in .735 seconds and the 's' search produced results in .125 seconds. So for files around the 2Mb size Copernic is virtually useless. 26 seconds is way to long to have to wait to see the context. All Copernic would need to do to FIX this problem would be to put a SSDS call right at the preview stage, instead of notepad or wordpad or whatever they currently use.
Seems nobody is even coming close to reproducing my test results, rambling on about SSDS times of a minute and 20 seconds or so. Obviously nobody has tried this simple test. I will post a screen captures of the copernic results and keep updating it as TIME passes. The results will have my x on it. Certifying it official.
First, your screen capture tells me nothing except that you pressed "Print Screen" 29 seconds after you started the search. For that matter, I'm not familiar with Copernic so maybe it was 29 seconds after it finished the search. I have no way to tell. No context.
Secondly, IT'S A FREAKING WEB FORUM. Google provided all of the instances of "388205283" in the entire thread, with links directly to the original posts and with complete context, in 0.08 seconds, and I never even had to merge anything anywhere.
Your numbers aren't accurate because you're not including the time required to put the text into your search file. Sure, you maybe found some text in slightly less than a second, but how many seconds did you need to get it into the file being searched?
[url=http://www.google.com/search?q=388205283+7593+site:thedailywtf.com&hl=en&rls=com.microsoft:en-us&filter=0]Verify my results here[/url]
