Slow quick search with /t switch compared to standard search

[Pagat]

Hello,

first things first: XYplorer: 28.30.1300 (64-bit). Other data see signature.

after years (decades?) of smooth sailing with XYplorer i want to clarify something where i'm not sure if it's a bug or by design:

I have a tag.dat database with ~20k entries. All of them on a network location path. When i search for tags via the "standard search" (Info Panel | Find Files | Tags) the result shows almost immediately. This is expected and fine as the tag.dat is searched first when i search (only) for tags.

However, if i do the same search via Quick Search with the /t switch (e.g. "tags:Dogs /t") the search takes ages to complete. Looks like the quick search first enumerates the file system (network path) and only afterwards cross checks against tag.dat (whereas the normal search apparently does the opposite).

Is this by design (i.e. Quick Search can only work this way for some reason) or is this a bug. Or did i overlook something?

[highend]

Mh, tag database is here:
\\192.168.0.50\int_01_crypt\SharedTags.dat

Using the current beta it takes ~7-8 seconds until the search result is displayed.
The search time is identical regardless if I use QuickSearch with tags:Dogs /t
or the standard search with "Dogs" in tags

35810 items are tagged, 19998 items contain the tag "Dogs"...

[admin]

7-8 seconds is very slow for the /t switch. Is it faster in the 32-bit version?

[highend]

No, about the same performance. Note that all tagged items are inside the network location as well, not local (that's what the OP uses if I understand him correctly)...

[admin]

Are you saying that 7-8 seconds is expected in this context?

[highend]

Can't say. I'm not a tagging guy, I've only done the tests because of the post.

Code: Select all

    $start = now("msecs");
    $a = quicksearch("tags:Dogs /t", , , "o");
    status "Time: " . now("msecs") - $start . " msecs";

~8000 msecs

And this doesn't include any displaying of the items.
I wouldn't call it fast

Have to leave now, a concert in Hamburg...

[admin]

Have fun!

[Pagat]

Ok, some more context: This scenario takes place in my Image Organization instance of XYplorer (own configuration, own tag.dat). In this instance i basically only browse the network path \\NAS\photos\ which is a network share in my local network. The files in tag.dat are also stored with UNC paths (not with a mapped drive letter). In tag.dat 21245 files are tagges (which are 99% of all files in this network folder). I also did this on a "fresh" config of XY (only tag.dat was updated).

I do both searches from the root folder \\NAS\photos:

Standard search for tag "Dog": found 171 files. Status bar says: "search done in 901,3 ms (scanned 21.245 items in tags database)
Quick search "tags:Dog /t": first results appear after 23 seconds.

So even though highend cannot replicate the difference between standard and quick search, do you have any idea what might be the root cause of the differences on my system?

[admin]

Looks like a bug. It's on my list.

[admin]

Perform the tags:Dogs /t quick search, then call script text <get find_queryparsed>;. You should get something like this (the crucial line here is Tags DB Only: Yes):

Code: Select all

Query:  tags:Dogs /t
Parsed: Tags:dogs

Search: Quick Search
Mode: Auto
Smart Boolean Query Parsing: No
Extended Pattern Matching: No
Master Invert: No
Tags DB Only: Yes

Match Case: No
Whole Words: No
Invert: No
Ignore Diacritics: No
Path: No
Find Hidden: No

Search Path: Desktop\Test\a\
Quick Search Pattern: tags:Dogs /t
Include Subfolders: Yes
Follow Junctions: No

[Pagat]

My result for the quick search:

Code: Select all

Query:  tags:Dogs /t
Parsed: Tags:dogs

Search: Quick Search
Mode: Auto
Smart Boolean Query Parsing: No
Extended Pattern Matching: No
Master Invert: No
Tags DB Only: Yes

Match Case: No
Whole Words: No
Invert: No
Ignore Diacritics: No
Path: No
Find Hidden: No

Search Path: \\NAS\photo\
Quick Search Pattern: tags:Dogs /t
Include Subfolders: Yes
Follow Junctions: No

And it's funny that this code snippet return "Tags DB Only: No" for the standard search (Info Panel | Find Files | Tags where it definitely just searchs the tag.dat due to it's speed:

Code: Select all

Query:  *
Parsed: Name:*

Search: Find Files
Mode: Standard
Smart Boolean Query Parsing: No
Extended Pattern Matching: No
Master Invert: No
Tags DB Only: No

Match Case: No
Whole Words: No
Invert: No
Ignore Diacritics: Yes
Path: No
Find Hidden: No

Search Path: \\NAS-Wohnung\photo
Include Subfolders: Yes
Follow Junctions: No

[admin]

Yes, I saw that too, it's a bug in <get find_queryparsed> that's fixed in the next beta.

So, both should have the same speed, but in your case they don't?

[Pagat]

Yes, as described. Even in a "fresh" installation with just the customized tag.dat.

[admin]

I can neither reproduce it nor explain it. Both ways run the same code.