How does Count: work?

[ChrisGreaves]

Everything 1.5.0.1333a (x64)

I have 346,753 objects on my system (C: and T:)
I ask for "*.doc count:10" and Everything responds instantly with ten document files, all with Date Modified today (2/2/2023) which does not surprise me.
Then in the results list I click on the Date Modified column heading and ten Document files from 1998 appear. That too makes sense.

That second set of ten files appears so quickly I have to ask myself, and now you:-
Does Everything build a list of 15,291 *.doc objects and hold that in hand, then produce the sorted list of most-recent files and subsequently re-display oldest files from the list in hand, or when I click to sort the result list by date modified, does Everything return to the database an rebuild the Result list for *.doc and re-sort that subset?

This is, I confess, an academic question, but I continue to be surprised by the fast response.
Thanks, Chris

[void]

Changing the sort order when using count: will force Everything to perform a requery.

The requery will perform a fresh search. (doesn't use existing results)

The search and sort is typically instant due to searching with presorted indexes.
For example, you asked for 10 items and you are sorting by date modified descending.
Everything will search using the presorted date modified indexes.
Once the number of results hits the count: quota, the search stops.

If you use a sort order that is not presorted, Everything will perform your query (ignoring your count: search), sort the results then remove any results that exceed your specified count:
This can take a long time.

[ChrisGreaves]

Everything will search using the presorted date modified indexes.

And I have date modified index checked ON in Tools, Options, Indexes, so to my eyes the change is instantaneous; it is a RAM search rather than a HDD search (and yes, I still spin platters)

If you use a sort order that is not presorted, ... This can take a long time.

Which is what I see now.
I have some 47,000 JPEG images on my system.

Code: Select all

*.jpg

gives instantaneous results
whereas

Code: Select all

*.jpg dimension:>10000x10000

starts at 47,000 objects and then painfully drops down at a rate of about 1,000 objects per second.

So "dimensions" is probably reading the content, or at least the header (or "metadata"), of each of 47,000 files to inspect the pixel dimensions, because dimensions does not have an index.

I'm not asking for an index; I'm just poking Everything with a stick to see how it reacts!)
Thanks, Chris

[ChrisGreaves]

So "dimensions" is probably reading the content, or at least the header, of each of 47,000 files to inspect the pixel dimensions, because dimensions does not have an index.

Heh heh!
Let's see if I can pre-empt your reply:

Code: Select all

*.jpg size:>3000K dimension:>10000x10000

is a more sensible filter, because images greater than 10,000 pixels will be large files, so I can use my index for SIZE to make a subset of only 5,000 JPG files and THEN search the dimensions on that.
I think I'm correct on that.
If so I'll take a break and shovel some more snow (sad!)
Cheers, Chris

[void]

As you guessed, Everything will find files with a size over 3000KB first as the size information is indexed.

Everything will only need to gather the dimensions property for the large files. (instead of all *.jpg files)

[ChrisGreaves]

Everything 1.5.0.1337a (x64)

Still poking Count: with a stick:-

Code: Select all

ext:doc;txt count:15

Untitled.png (58.6 KiB) Viewed 1748 times

Code: Select all

ext:doc;txt count:15

yields the same results, regardless of whether in ext: I use doc;txt or txt;doc. The text files always appear first.
I know (now!) that I can randomize, or sort by type and so on, but am puzzled about TXT seeming always to appear first.
Is this on account of the way the Result List is assembled, or is it related to the way Everything processes its indexes and databases?

I confess: I started with DOC and then added TXT expecting the second essay to show a variety of types.

Untitled1.png (70.35 KiB) Viewed 1748 times

Even more puzzling to me is that when I add a Content: function, the result list now shows a variety of extents.
But I receive sixteen results when I asked only for 15. Langiappe?
Thanks, Chris

[raccoon]

Code: Select all

ext:doc;txt count:15

yields the same results, regardless of whether in ext: I use doc;txt or txt;doc. The text files always appear first.
I know (now!) that I can randomize, or sort by type and so on, but am puzzled about TXT seeming always to appear first.

You were using a Path sort in that query, and it happens that the first 10 results by Path are all txt files. Sorting by Path will always show results from \Program Files before it reaches your \Users directory where all your doc files are stored.

I can't explain the 16th result in your last query. Sounds like a simple off-by-one error, or that file recently changed while the content search was being performed and was added to the bottom of the list after the count:15 crop happened.

[ChrisGreaves]

You were using a Path sort in that query, and it happens that the first 10 results by Path are all txt files. Sorting by Path will always show results from \Program Files before it reaches your \Users directory where all your doc files are stored.

Untitled5.png (42.45 KiB) Viewed 1724 times

Magnificent! Thank you Raccoon. So when I removed all but the Name heading, the result list was fabricated in unsorted sequence; at least, perhaps chronologically by DateTime of discovery.
Being a sneaky little devil, I, of course, decided to see what happens when I check ON, say, Attributes, and check OFF Name, which, in theory, would give me an almost meaningless result.
But I see that one "@void" has already beaten me at that game

I can't explain the 16th result in your last query. Sounds like a simple off-by-one error, or that file recently changed while the content search was being performed and was added to the bottom of the list after the count:15 crop happened.

Code: Select all

ext:doc;txt count:15 content:greaves

Hmmmm!. I still get 16, although now I am but a lowly Standard User (grin).
Can we leave this in the too-hard basket for now? There is a chance that other counts are out by a unit or more, but I am unlikely to spot such an error when I receive 15,293 objects; more likely when I am specifying either low Count:s or else fine-tuned results.
Cheers, Chris

[void]

Hiding columns will not change your sort order.

Everything is most likely sorting by date modified here, so the 15 most recent files are displayed.

Even more puzzling to me is that when I add a Content: function, the result list now shows a variety of extents.
But I receive sixteen results when I asked only for 15. Langiappe?

This is a bug.
Thank you for letting me know.
Everything was allowing one file to be added (due to a file change) when there was 15 results.
The next alpha update will not add new results when the count: quota is reached.

[ChrisGreaves]

Hiding columns will not change your sort order.

This now makes sense to me. Whenever any sort of list is displayed (not just Everything's Result List, but even my grocery shopping list on a scrap of paper), there has to be some order, even if it is apparently random.
If I were Everything, I'd have to make a decision as I wrote, or after I had written, the Result List.
I'd probably go, by default, with the latest sequence selected (by the user, or by Everything if there was a powerful reason for Everything to use a new sequence)

Even more puzzling to me is that when I add a Content: function, the result list now shows a variety of extents.
But I receive sixteen results when I asked only for 15.

This is a bug.

Good to know, sort of.
As I think I mentioned, the bug will not be apparent to the user when 15,293 objects are involved. What human is going to check each of 15,293 results?
The bug would make itself known only when 15,294 objects had been moved/deleted and one of those files happened to be a critical file e.g. Payroll.MDB.

Or when a novice was playing around with Count:
Thanks again
Chris