lsd is slow Windows

Question

lsd is slow Windows

Closed this issue a year ago · 20 comments

Performance is very slow - about 50 seconds to list a few files.

The long delay appears to be in calling lsd::meta::windows_utils::get_acl_access_mask.

Possibly relevant details - I'm testing on Win10 1903 on a domain joined machine. I suspect the issue is contacting the domain controller, because when I disconnect the machine from the network, lsd.exe gives me this error:

cannot access '.': The specified domain either does not exist or could not be contacted. (os error 1355)

I also tested on a non-domain joined machine (Server 2016) and it seemed plenty fast.

Answer 1 · 2019-05-21T10:21:53.000Z

Is windows even supported?

Answer 2 · 2019-05-21T10:24:43.000Z

Hi!

Is windows even supported?

Yep but it's in early stage for now. I will soon add some documentation into the README.

Answer 3 · 2019-05-21T10:25:58.000Z

Cool, because I was surprised to see Windows issues when I couldn't find anything in the readme. Nice! I will also try it in my secondary windows machine

Answer 4 · 2019-06-03T05:36:04.000Z

I tried in Windows and it is as fast as in WSL, sometimes faster. But I do sometimes come across the error cannot access '.' if -a is passed. This error also sometimes happen in WSL when accessing files in Windows.

Answer 5 · 2021-01-28T06:43:23.000Z

very very very slow in win 10, listing a directory with four sub-folders will cost one minute or more.
In WSL, its speed is normal.

Answer 6 · 2021-04-21T06:29:40.000Z

Any news on this? The same directory works great in WSL but takes over 20s on Git Bash for me.

Answer 7 · 2021-07-05T13:28:21.000Z

I've ran a profiler at it and the problem is all the calls to GetEffectiveRightsForAclW:

Answer 8 · 2022-01-24T22:06:59.000Z

generally 1/10 speed of ls

Answer 9 · 2023-03-02T03:38:33.000Z

#817 (comment)

This program has a severe performance problem on windows when the number of files to read is large (30+), it blocks almost 100ms untill it starts to render with Core::display, I dug on the issue and its located on the Win32 call to GetEffectiveRightsFromAclW, I don't know why is so expensive.

Proposed solutions:

Figure out why that function call is so expensive (maybe we can't solve it)

Be more inaccurate on windows about the permissions of the user and group (since its not very relevant on windows systems), for example the libcxx of llvm obtains the permissions of a file assuming its read only and then just checking if the property FILE_ATTRIBUTE_READONLY is set or not, assume that everything is executable and similar "inaccurate stuff"

Change the creation of the Meta struct to only retrieve the owner/group permissions if its really needed to display

Hope this helps

@cdecompilador please discuss the performance issue on windows here

Answer 10 · 2023-03-02T03:40:50.000Z

#484 has some works in progress

Answer 11 · 2023-03-07T12:15:09.000Z

I don't know Rust, but is there anything i can do to help #484 go forward? It seems that the (last?) hang up is regarding the PR code coverage?

Answer 12 · 2023-03-08T03:27:22.000Z

hi @ArnaudKunzi, it seems there is not only the coverage, some discussions need to be resolved, and added some of mine just now, let's try to make it happen in the near future.

Answer 13 · 2023-03-24T09:55:10.000Z

Would that help if I tried to fork @vvuk's PR #484 and resubmit it with the requested changes?
He doesn't seem to have much time at the moment.
Not sure to get it right on the first try but it seems rather straightforward. I just don't want to cause unnecessary confusion/duplication and waste the maintainers time.

Answer 14 · 2023-08-18T10:41:59.000Z

Any progress on this issue?

Answer 15 · 2023-08-18T10:48:23.000Z

The PR needs to be rebased to the latest main branch version but I don't have sufficient knowledge to solve all conflicts and accommodate the other changes that happened since, so unless someone else fixes it, this is it.

Answer 16 · 2023-08-18T10:54:28.000Z

The PR needs to be rebased to the latest main branch version but I don't have sufficient knowledge to solve all conflicts and accommodate the other changes that happened since, so unless someone else fixes it, this is it.

have you asked for help/support from the other contributors?

Answer 17 · 2023-08-28T08:29:45.000Z

Even the latest lsd-1.0.0 the slowness is there:

PS> .\lsd.exe --version
lsd 1.0.0
PS> (Measure-Command { & .\lsd.exe }).TotalSeconds
14,4527767
PS> .\lsd.exe
 autocomplete   LICENSE   lsd.1   lsd.exe   README.md

Answer 18 · 2023-08-28T10:37:41.000Z

as v1.0.0 is finally released, I will spend some time on this, We may improve this step by step, but I can not guarantee any time schedule...

it's welcome for any PR improvement to be sent!

Answer 19 · 2023-08-28T12:01:26.000Z

I have a look at #484, and it is not difficult to implement as an option, so I did a POC

Any comment is welcome, and we could do it in this way if it works for people who meet this problem.

Answer 20 · 2024-02-04T11:40:31.000Z

in my test.
version: lsd 1.0.0 eza v0.18.0

===
on wsl2

time (lsd -alih --icon=always -R)

real    0m5.525s
user    0m1.701s
sys     0m1.268s

time (Downloads/eza -alih --icons=always -R)

real    0m12.055s
user    0m5.418s
sys     0m13.722s

===
on windows

Measure-Command { lsd -alih --icon=always -R }

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 2
Milliseconds      : 996
Ticks             : 29965805
TotalDays         : 3.46826446759259E-05
TotalHours        : 0.000832383472222222
TotalMinutes      : 0.0499430083333333
TotalSeconds      : 2.9965805
TotalMilliseconds : 2996.5805

Measure-Command { eza -alih --icons=always -R }

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 487
Ticks             : 4878319
TotalDays         : 5.6462025462963E-06
TotalHours        : 0.000135508861111111
TotalMinutes      : 0.00813053166666667
TotalSeconds      : 0.4878319
TotalMilliseconds : 487.8319