- results.PNG (915 Bytes) Viewed 1809 times
Is there a way to display omitted object count in the status bar?
Re: Is there a way to display omitted object count in the status bar?
Currently, no.
It's rather difficult and expensive to calculate this information.
An option to do this is on my TODO list.
Thank you for the suggestion.
It's rather difficult and expensive to calculate this information.
An option to do this is on my TODO list.
Thank you for the suggestion.
Re: Is there a way to display omitted object count in the status bar?
The number can be seen immediately after omitting disabled though. How it is expensive to calculate?
Re: Is there a way to display omitted object count in the status bar?
Everything would have to build and maintain a list of omitted results.
This will more than double the time it takes to perform a search.
I am considering an option to show the total number of omitted results as you might not mind this performance hit.
Everything aims to be as fast and efficient as possible.
This will more than double the time it takes to perform a search.
I am considering an option to show the total number of omitted results as you might not mind this performance hit.
Everything aims to be as fast and efficient as possible.
Re: Is there a way to display omitted object count in the status bar?
I'm just curious of the technical hurtles. I'm not entirely sure how Omissions (formerly Temporary Excludes) and Temporary Omissions (Temporary-Temporary Excludes) work in the background, in relation to the primary Index database.
Are Omissions and Temporary Omissions completely wiped from the Index DB, and so, would disabling Omissions or removing (re-allowing) any omitted objects force a complete rebuild of the Index DB?
Or are omitted objects kept safe in a side DB to be tracked and later re-added to the Index DB when Omissions are disabled?
Or are omitted objects kept in the primary Index DB and simply "flagged hidden", thus automatically filtered-out/skipped-over with every search query?
I would suppose a simple i++ tally could count filtered omissions that [would] match the search query, if they're still kept around in the main or aside Index DB, somewhere, unless they're forgotten about entirely (like permanent Excludes are).
Are Omissions and Temporary Omissions completely wiped from the Index DB, and so, would disabling Omissions or removing (re-allowing) any omitted objects force a complete rebuild of the Index DB?
Or are omitted objects kept safe in a side DB to be tracked and later re-added to the Index DB when Omissions are disabled?
Or are omitted objects kept in the primary Index DB and simply "flagged hidden", thus automatically filtered-out/skipped-over with every search query?
I would suppose a simple i++ tally could count filtered omissions that [would] match the search query, if they're still kept around in the main or aside Index DB, somewhere, unless they're forgotten about entirely (like permanent Excludes are).
Re: Is there a way to display omitted object count in the status bar?
Both Omit results and Temporary omit results use a separate database.
When you add a result omission filter, all files/folders matching that filter are added to the Result omissions database. (as a pointer)
This Result omissions database is maintained in real-time.
For example, if you remove a file, it is removed from the Result omissions database.
If you add a file that matches a result omission filter it is added to the Result omissions database.
So your result omission filters are applied when files are added/deleted.
When Everything performs a query, it can check if each file/folder is in the result omission database instantly. (just a pointer lookup / a couple if statements)
The Omissions and Temporary Omissions databases are rebuilt from the text filters each time you start Everything.
Each time you change Omissions and Temporary Omissions the entire Omissions and Temporary Omissions database is rebuilt.
There's some optimizations here, adding a file to the Omissions and Temporary Omissions is generally instant without a Omissions and Temporary Omissions database rebuild.
Your result omissions as text filters are stored on disk in Omit Results.csv
Omissions and Temporary Omissions never touch the normal index DB.
There's a separate Omissions and a separate Temporary Omissions database.
You need another database to check if the omitted result has already been counted.
I don't think the performance would be quite as bad as stated above. (~x2 search time)
Building and maintaining this tally database is not free.
I'll look into getting something going and if performance isn't too bad I'll enable it by default.
Omit Results
When you add a result omission filter, all files/folders matching that filter are added to the Result omissions database. (as a pointer)
This Result omissions database is maintained in real-time.
For example, if you remove a file, it is removed from the Result omissions database.
If you add a file that matches a result omission filter it is added to the Result omissions database.
So your result omission filters are applied when files are added/deleted.
When Everything performs a query, it can check if each file/folder is in the result omission database instantly. (just a pointer lookup / a couple if statements)
Omissions and Temporary Omissions databases are not stored on disk.Are Omissions and Temporary Omissions completely wiped from the Index DB, and so, would disabling Omissions or removing (re-allowing) any omitted objects force a complete rebuild of the Index DB?
The Omissions and Temporary Omissions databases are rebuilt from the text filters each time you start Everything.
Each time you change Omissions and Temporary Omissions the entire Omissions and Temporary Omissions database is rebuilt.
There's some optimizations here, adding a file to the Omissions and Temporary Omissions is generally instant without a Omissions and Temporary Omissions database rebuild.
Your result omissions as text filters are stored on disk in Omit Results.csv
Omissions and Temporary Omissions never touch the normal index DB.
No flags are used here.Or are omitted objects kept in the primary Index DB and simply "flagged hidden", thus automatically filtered-out/skipped-over with every search query?
There's a separate Omissions and a separate Temporary Omissions database.
It doesn't work because each time you test if a file should be omitted, you'll increment the tally.I would suppose a simple i++ tally could count filtered omissions that [would] match the search query, if they're still kept around in the main or aside Index DB, somewhere, unless they're forgotten about entirely (like permanent Excludes are).
You need another database to check if the omitted result has already been counted.
I don't think the performance would be quite as bad as stated above. (~x2 search time)
Building and maintaining this tally database is not free.
I'll look into getting something going and if performance isn't too bad I'll enable it by default.
Omit Results