blog: xplorer2 v6.3 (final) released

[Kilmatead]

Not sure if ES even has a "shuffled" mode or not, but the EXE/DLL game (since that's the slow one) presorted by path (assuming that means "folder"?) still gives me a 3 minute cigarette drag. (Geddit? See what I did there?) If I still smoked, that is. <Sigh> I miss smoking.

[nikos]

try sorting the results by path and see if it makes any difference

[Kilmatead]

I can understand you not reading my longer posts (busy busy boy like you gots important nonsense to pretends to do), but the post above has only two sentences, one of which contains the words "presorted by path".

You'd walk into traffic if you weren't chained to your sailboard, you would.

[nikos]

this is all your fault for having acclimatized me over the years not to expect anything of substantial on-topic content in your blabber

[Kilmatead]

Ok, so revisiting this at the risk of incurring the inevitably condescending riposte from Nikos involving the phrase "Would you ever just get a life already?", I stumbled upon a strange ES frame-population timing thing which I can't quite figure out.

So I did a quick (system-wide) search of es:regex:\(\d{4}\) in a scrap window.

This returns 7,515 results - matching anything with a 4-digit year within parentheses. This breaks down into 7,325 folders and 284 files of varying types (mp3, mkv, lnk, etc).

What's weird is that (according to search status) it takes upwards of 220 seconds (3.6 minutes!) to 255 seconds (4.3 minutes!) to do the search (I ran it numerous times to get a mean).

Now, obviously as it uses ES the search is essentially instant, so this is yet another population issue. Just to completely rule-out anything funny going on, I whipped up a quick programme which does the same search in ES but dumps the output into a 7,515 line text-file. This takes a negligible 22 milliseconds (so it's not the search/regex/etc).

This is where I got curious - since I had a text file with the results anyway, how long (I wondered) would it take to load that into a scrap window? So, selecting Actions -> Load Contents (selecting .txt instead of .cida), it takes an average of only 6 to 7 seconds to load and render the results!

WTF? I understand that collating from internal ES results you've got some "behind the scenes" work to do, but doubtless the same would apply to reading a 7,515 line text file of full paths... yet one takes 4 minutes and the other takes 6 seconds?

Your optimisation attempts (while better than they were at first) still seem woefully suboptimal.

[nikos]

the situation is more complex than that as when you search from x2 there is interprocess ommunication involved
I can send you a special profiling version of xplorer2 to investigate the cause of the unexplained delay

ps. try the same search in deskrule v2.93 (latest), it also uses ES

[Kilmatead]

the situation is more complex than that as when you search from x2 there is interprocess ommunication involved

Are you forgetting who's asking the question? I'm the IPC guy! As the search demonstrably takes ~30 milliseconds at best, the rest is sorting which shouldn't take 4 minutes - IPC's got nought to do with it. Why can a text file of the same list load in 6 seconds?

I can send you a special profiling version of xplorer2 to investigate the cause of the unexplained delay

Kenny needs his speedy-gonzales makeover!

try the same search in deskrule v2.93 (latest), it also uses ES

Aside from the fact that I can't figure out how to do a regex search in DR (just to do a like-for-like comparison), I can do an "idiot search" and it collates 12,000 folders in a second or two, but I'm at a loss to ascertain the involvement of ES (should I still be disabling that MFT stuff like I have to in x2?)

And who designs a programme without a real menu anyway? Pseudo-modern UX gives us old-skool hacks hives! Bring back John Cusack movies!

[nikos]

deskrule is "idiot proof"
if it sees regex chars in the string, it makes it regex (see [RE] in the search description on the titlebar
i don't think it would find 12000 results quickly on its own... check the statusbar messages during search

[Kilmatead]

if it sees regex chars in the string, it makes it regex (see [RE] in the search description on the titlebar

Curious - that didn't work the first time I tried it, but now it does - weird. So it's using ES to find 3,603 items (folders) in 1.2 seconds, so that works as expected. How do I force a system-wide search of multiple drives just for fun? Selecting "This PC" doesn't do doodle. Idiot-proof? Bah! Edit: Aaargh! Now it's saying searching MFT for the same thing! Nutters, all! (I even turned on "ignore search index").

The same delimited search in x2:

ES QUERY
f:\ regex:\(\d{4}\)
Operation total time: 89.922 sec

~3700 results

1.5 minutes vs 1.2 seconds? Hmm! What kind of hair-emporium are you runnin' here, Popeye?

I should also mention that the x2 scrap statusbar is NOT showing the running item-count like it's supposed to (until after the search completes fully - just showing that lilac-coloured in-progress-thingy).

[nikos]

so the problem is in x2 only, back to the drawing board