Drag & Drop From Everything Seems Slow(er)

[therube]

Drag & Drop From Everything Seems Slow(er) then I remember.


Everything 1367

(highlight) & drag 18K (Randomize) items (into mpv.net) was slow, showing:
- "Buiding item list..."

i don't recall seeing anything like that before (& not uncommon
for me to drag & drop a large lists [though i may not have had
it in Randomized sort order before])

(seems sort order is immaterial)


(I didn't test [yet ?] older versions to see if I notice the same.)

[void]

Please try enabling drag_drop_simple_pidl:

• In Everything 1.5, from the Tools menu, click Options.
• Click the Advanced tab on the left.
• To the right of Show settings containing, search for:
  pidl
• Select: drag_drop_simple_pidl
• Set the value to: true
• Click OK.

When enabled, Everything will use a simple filename only PIDL. (pointer to an Item ID List)
This might break some programs as they might be expecting more information.

Drag-dropping simple PIDLs will be much faster.

drag_drop_simple_pidl

[therube]

(Before I saw above, & I tested against 1358 - because it was there.)


video: distinct: count:18000
drag&drop from Everything into mpv.net


1358: 9.790 seconds
1367: 10.294 seconds

so... it's the same

it must have just been the (new) "wording", & the progress meter
that made it appear that the "issue" was Everything
where in fact it is simply being enumerated making it appear the the issue was Everything...

• 1367... messing around (with this), i went to 100% CPU & ...
  & i'm not sure quite just what?
  did it hang? did it... not sure?
  i did not kill it, but did get out of it, cleanly?

count:36000 (try 2)

1358: 31.551 seconds
1367: 31.245 seconds

so... whatever i did, however i came about it (to cause Everything to eat 100% CPU),
oh, not quite sure. i was using 2 different Profiles, initially, then (try 2)
i switched over to 1 Profile, but subsituted the different .exe's

& since you asked

count:72000

1358: 1:58.941
1367: 2:04.646

so once again, same time

(control seemed to return to Everything fairly quickly, well before, relatively,
mpv.net was able process the list & start playback.
the times listed are the point in time when playback did start in mpv.net.)

Code: Select all

C:\DEV\Locate\15.1364 vs 1359 - MULE - zoom size col width issue - BUST>timethis pause

Press any key to continue . . .

TimeThis :  Command Line :  pause
TimeThis :    Start Time :  Mon Feb 19 22:03:19 2024
TimeThis :      End Time :  Mon Feb 19 22:05:18 2024
TimeThis :  Elapsed Time :  00:01:58.941

C:\DEV\Locate\15.1364 vs 1359 - MULE - zoom size col width issue - BUST>

[therube]

1367... messing, i went to 100% CPU

Wasn't able to duplicate.
I've never seen that before. And overall system performance didn't seem to be affected, particularly. Anyhow.
.

Everything - 36K items drag drop 100% CPU.png (39.32 KiB) Viewed 303 times

[therube]

yes, pidl change certainly makes a difference
30.sec vs. 2.min

Code: Select all

Press any key to continue . . .

TimeThis :  Command Line :  PAUSE
TimeThis :    Start Time :  Tue Feb 20 20:50:59 2024
TimeThis :      End Time :  Tue Feb 20 20:51:28 2024
TimeThis :  Elapsed Time :  00:00:28.748

[void]

1367... messing, i went to 100% CPU

If you see this again, could you please create a mini crash dump.

• Download Process Explorer from Microsoft:
  https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer
• In Process Explorer, select Everything64.exe (If there is two, select the one using the most memory)
• Right click Everything64.exe and under Create Dump, select Create Mini Dump.
• Choose a filename and click Save.
• Please send this file to support@voidtools.com

The mini crash dump will show exactly what Everything is doing to help determine the CPU spike.

yes, pidl change certainly makes a difference
30.sec vs. 2.min

I will trial having simple PIDLs enabled by default in the next alpha update.