Possible bug with filters

[vsub]

When I scan the windows recent folder(where he create shortcuts for the last started file\folder),it takes a lot of time to scan the files(probably it will never stop)
dm:
dc:
da:
attrib:
size:
type: - this one actually finish scanning quickly but it was still slow

Does Everything tries to scan the actual file,not the .lnk
The folder have 400 shortcuts and it takes a lot less time(instantly)to sort the files by anything.

[vsub]

It looks like the problems is something else.
If you use for search when creating the filter:
1.Some word
2.Some path
3.Extension(.ogm for example)

Even if I create a filer with .ogm for the search(I have only 15 files with that extension),if I try using any of the above modifiers,it will scan at least 10 seconds

If I search for everything using this .ogm dc:,the result is instant,but if I use search filer which contains .ogm,it take a lot of time to display the result(first time only)

If the scanning finish at least once,any of the modifiers will works fast until you close the window or exit the program

[vsub]

Sorry for the third reply but it looks like this applies to all filters
Using any of the filters and just type dc:today take a lot more time than typing any of the filters macro and dc:

Searching using the Everything filter with this for example
zip: dc:today - instant result
Searching using the Compressed filter(Ctrl+Alt+3)
dc:today - 50 seconds

[void]

Filters are applied after the search.
This would be causing the slowness you are seeing.

I will look into prioritizing faster filters so they are processed first.

Thanks for the suggestion.

[vsub]

Yes,that seems to be the problem,and that will definitely better(first apply the filters and then what you typed in the search field)

[void]

I'm not sure applying filters first would be the best approach, for example if I had a filter: Today that searched for dm:today
It would be faster if the filter came last.

Letting Everything determine which order might be best or let the user choose the order in the filter..

[vsub]

I mean,when you switch to another filter(not everything),everything immediately applies the Search in Edit Filter so everything you type will come faster.

As I said,searching in the Everything filter for
ext:all compressed extensions
or
zip:
and then type what you are searching for(dm:,dc: and so on),display the result instantly but searching something by using some of the other filters(drop down list),takes a lot of time to display the result(first time only)

ext:all compressed extensions dm:today - instant result
zip: dm:today - instant result
Compressed Filter(drop down list) dm:today - 50 seconds

So when switching to some filter(drop down list),apply the limit to what you will be search for immediately

[vsub]

I'm not sure applying filters first would be the best approach, for example if I had a filter: Today that searched for dm:today
It would be faster if the filter came last.

Letting Everything determine which order might be best or let the user choose the order in the filter..

If you don't want to change it that way can you at least add some option to tell what to be the default behavior.
Applying the search string to the list created by the filter

It just takes really long time to use any of those
dm:
dc:
da:
attrib:
size:
if the filters are applied after the search.

Today I wanted to find one archive that was created this month but I forgot the name...it took like forever to display the list when I used dc:thismonth while compressed filter was active and immediately while the Everything filter was active and I searched for this zip: dc:thismonth

[nagan]

Let me recount my experience with similar circumstances in XP SP 3 ET 658b

1.The first time you open/maximise the ET window in a session and make a query or sort , ET is going to take a very huge time since it creates a cache from the disk and the speed is around 340k /unit time whereas the database builds up at greater speed.

2.If after step 1 the window were closed and then maximised ,query/sort is made ET will work from the Windows cache (if available that is) which will be fast .

3.If after step 1 it was minimised or left as it is ,a query /sort made will be immediate because it will work from its own cache.

I tried dc:thismonth and also a date range , with the built in video filter and also the Picture filter and the results were immediate. The time difference in the two methods you mentioned could be in micro seconds but not so huge.

Would you give the query using filter a try without closing the window and see if there is any difference?
Void has added a feature to hide the ET Window to utilise the ET cache in the future versions.

[vsub]

I tried dc:thismonth and also a date range , with the built in video filter and also the Picture filter and the results were immediate.

They are because you already did a scan on the whole database

Would you give the query using filter a try without closing the window and see if there is any difference?

It will only be quick if you already did a scan on the whole database.
All of the test below are done on the everything filter like this...start the program and do a scan.When it's done,close the program(not the window),run it again and do the next test
audio: dc:thisweek - 4 seconds(5296 files total on the hdd)

video: dc:thisweek - 2 seconds(3508 files total on the hdd)

pic: dc:thisweek - 8 seconds(15958 files total on the hdd)

zip: dc:thisweek - 1 second(809 files total on the hdd)

exe: dc:thisweek - 1 second(2203 files total on the hdd)

doc: dc:thisweek - 10 second(16764 files total on the hdd)

file: dc:thisweek - 54 seconds(97510 files total on the hdd)

folder: dc:thisweek - 6 seconds(10049 files total on the hdd)

file: dc:thisweek | folder: dc:thisweek - 60 seconds(107099 files total on the hdd)

dc:thisweek - 60 seconds(107099 items total on the hdd)

Now tell me again why do we need to make a scan on everything when you want to search for something from a filter?

Every time you close the program\window and try searching with dc:thisweek,you are doing scanning everything,not just the files you want(every time 1 minute wait)
During that time,the hdd indicator is flashing non stop and the cpu usage goes above 50% and this is every time

if you use filter first then search,every time you switch to another filter,it will take only the time needed to scan only the list created by the filer\macro

For example if you search for zip: ,it will take 1 second,if you then search for pic:,it will take 8 seconds.When you do a search using all of the filters,it will be the same as using file: |folder: or just dc:thisweek on the everything filter
Every next attempt to search will be real fast until you close the window\program

Or to say it with another words,searching for zip,will create a database with compressed files,if you then search for pic,it will add the images to the database which already contains the archives files

Void has added a feature to hide the ET Window to utilise the ET cache in the future versions

I know but that won't really help the problem I'm talking about

[nagan]

@vsub
You have a point here. Perhaps I was doing a query where it had already been done.So if it was a new ET opening every time .zip dc:today is immediate compared to dc:today with the zip filter (search .zip) on which inevitably scans the whole database again (or the cache if it is a recently closed and opened window). I think it happens only for filters (or combined with filters) and not on any specific extensions which is fast.For example .mpg dc:2012 is immediate but video: dc:2012 takes some time.Let us hope Void looks into it.

Another thing which you said that every time you make a query within the same session albeit with the close and open program , creates a continuous HDD flicker appears strange as I get only high CPU runs in the subsequent queries or sort which ET does from the Windows cache it builds when queried or sorted for the first time.

EDIT
Since ET is indexed by Name , Path , Extension , time perhaps a precedence like in operators for them?. Anytime after a HOT start (ie Within a session ET after making a query , thereby setting a Windows cache is closed and freshly opened) .jpg dc:2012 is immediate whereas dc:2012 .jpg is not. The point is a extensive query scan might have to be annulled and started again and again based on the search parameters as they are typed in the search bar which may not be very productive. Perhaps the hiding window feature will solve this for the time being till as Void proposes to do more on Indexing and database , so that more entities are brought into the indexing fold.

[vsub]

For example .mpg dc:2012 is immediate

That's because you already create a list with all .mpg files and the dc: modifier is applied only on that list,not the whole database

but video: dc:2012 takes some time.Let us hope Void looks into it.

It's little slower because you are doing scan on every single video file you have,not just the .mpg file(it's still way faster than dc:2012 without macro in front)

[nagan]

but video: dc:2012 takes some time.Let us hope Void looks into it.

It's little slower because you are doing scan on every single video file you have,not just the .mpg file(it's still way faster than dc:2012 without macro in front)

Err...It was meant to be the video filter when chosen from the Search > Filter
video: dc:2012 is faster than choosing the video filter from search and pressing dc:2012 which is same as dc:2012 video:

[vsub]

video: dc:2012 is faster than choosing the video filter from search and pressing dc:2012 which is same as dc:2012 video:

Yes.
Everything filter active and searching for video: dc:2012 - this is fast because the dc: is applied only on the list created by video:
Just dc:2012 on any filter is the same as dc:2012 on Everything filter because the dc: is executed on all files\folder and then the files\folders that don't match the filter are removed.

To put it simply,using modifiers on already created list(by search string or a filter\macro)is much faster than using modifier on not created list(like it is now)

Another example is by searching for a file\folder name and then apply modifier...again you get real fast result
images\ dm:today
First the filter\macro\search string and then the modifier

[nagan]

Finally , this is not a bug. The priority for functions may have to be changed form scan first to scan within results when nothing precedes them in the search box. If Everything is the filter , it builds up a good cache. If something else ,a faster search within the columns of the result.Also if an order of hierarchy like for operators is set for the functions + other items of search/results it could continually alter the direction of the scan , but can ensure faster results. Hope Void looks into this if it is worthy enough in the overall scheme.