Drag Drop few seconds to minutes

[SLowrAM]

I want from v1299a to v1313a, doing so made dragging and dropping 7800+ files go from a couple seconds to a couple minutes. Not sure what changed to cause this, or if there is some setting(s) I can tweak to get fast many file drag/drop working fast again.
There were 2 key features I loved about 1.5 going hand in hand 1 being I could randomize the view file list and drag/drop in 1.5 was nearly instant with thousands of files selected unlike previous releases.

[void]

Thank you for the issue report SLowrAM,

1312 and earlier used simple PIDLs (think of these as paths to identify files/folders) when selecting 2 or more results.
1313 and 1314 no longer use simple PIDLs to avoid issues with the properties details.


I will trial enabling simple PIDLs for drag drop in the next alpha update.
I'll make another post here once this is ready.

I will add an option to always use simple PIDLs.

[SLowrAM]

Fantastic, glad you know the cause, and are willing to add an option (simple PIDL) if needed - I know adding options gets tiring, really appreciate it. I had rolled back to 1299, will have to see about jumping to 1312 in the interim. Was happy rolling back went super smooth.

[void]

Everything 1.5.0.1315a adds the following ini settings:

context_menu_simple_pidl
drag_drop_simple_pidl
clipboard_simple_pidl

I will add an option to always use simple PIDLs.

Unfortunately, this will make some shell dialogs display the wrong information.
For example: Pasting a file with the same name as an existing file: Windows will show the filename conflict dialog with the incorrect size and date modified information.
For this reason, these options will be disabled by default.



If you would like to improve the drag drop performance in Everything, please enable drag_drop_simple_pidl:

• In Everything, type in the following search and press ENTER:
  /drag_drop_simple_pidl=1
• If successful, drag_drop_simple_pidl=1 is shown in the status bar for a few seconds.

[SLowrAM]

Finally got around to updating (seeing major additions), can confirm the /drag_drop_simple_pidl=1 is working as intended. I've installed v1333a before changing that setting about 3k drag drop files took a couple minutes (or more), after that setting about 10k files took a couple seconds. Thanks so much for taking the time to add this option. Happy New Year, I'll have to make another donation this year for the great ongoing work, the new findbar looks interesting as well as the many fixes and improvements.

[therube]

Everything to mpv.net.

Code: Select all

drag_drop_simple_pidl=   1 vs  0
21,178 objects           7 vs 11 sec (timed "manually")

What are you dragging to that you were seeing such a large time discrepancy?

[SLowrAM]

Fascinating drastically different results here, if the difference on 21k objects were a few seconds I wouldn't bother with posting. It takes well over a minute if I drag/drop 3,000 video files into mpv.net. Don't know if it's part of the timing difference, but I do add Created On date (set to be indexed) to my everything and many of the files are from (folders added for index) network folders (vs ntfs).

[therube]

Strange.

17,678 objects (on a NAS).

drag_drop_simple_pidl=0
- 13 seconds
drag_drop_simple_pidl=1
- 7 seconds


Indexing Date Created Property, made no difference.
(Actually, did I do that? I added pic: as Include filter. Did that do anything?)


In this case, 12.8 GB of pictures, in sizes between 78 K & 13 K (13 K in appreciation for Friday 13th. )
Win7, i7-3770s, 8GB RAM, Synology NAS, GB Nic - nothing special.
(Pics again dragged into mpv.net.)

[void]

Try timing how long it takes Everything to start the drag operation.

For example, how long does it take for Everything to show the drag cursor?



The drop operation is not handled by Everything.



For me, timings to show the drag cursor for 17,678 objects:

drag_drop_simple_pidl=0
- 13 seconds
drag_drop_simple_pidl=1
- 1 seconds

[therube]

It's the Date Created that is the issue.
Indexes, date created, fast sort.
And with that d&d is SLOW.

Heh.
Ignore that. I must have missed the drop.

For example, how long does it take for Everything to show the drag cursor?

What is a drag cursor?

Oh, #3, https://stackoverflow.com/questions/494 ... opy-cursor.


I typical don't see that.
I just d&d (& go on doing something else) "knowing" that it was done, rather then waiting to see any type of cursor change.


OK, so doing that (watching for the cursor change)...

drag_drop_simple_pidl=0
- 7 seconds
drag_drop_simple_pidl=1
- <1 seconds

[SLowrAM]

When I had drag_drop_simple_pidl=0 with > 1k video files selected and dragging into mpv.net with d&d being slow, everythingapp gets in a locked state I can't close it or do anything and it shows a spinning (wait) cursor when I try to do so, with drag_drop_simple_pidl=0 I've had to force it closed from an app manager when dragging 10k or more and not waiting for minutes.
I'm not sure what technically is going on with setting drag_drop_simple_pidl=1 but that gets mpv.net to immediately start playing video (couple seconds) vs taking minutes. Then if I've dragged thousands of videos everything stays focused for a second (not letting me change focus to mpv.net, noticed this when volume was too loud ) as if it's still doing some processing or waiting for an mpv.net drop end response or something, just a second but noticeable delay before regaining control.
It's interesting to see there's more to the issue than I realized as I expected everyone had this behavior (if they were dealing with more than hundreds of files). It may be some other software or hardware issue, but it seems odd (not knowing technical details) why simply changing the pidl would cause such a major difference for my setup.

[therube]

(Since I did it, just noting...)

drag_drop_simple_pidl=0
21,365 objects, 904 GB
took ~30.sec for drag cursor to show up [d&d into mpv.net]