feat: reduce amount of syscalls

[Brijeshkrishna]

eza version v0.14.1 [+git]

eza syscall trace

ls syscall trace

Info

The folder ./target/debug/deps/ ( example folder , any folder with large number of files ) contains 677 files. ( all numbers based on this folder ). I tested multiple times to come to this.

readlink

eza makes 2708 readlink syscalls, which all fail. This syscall takes around 50-60% of the execution time. "ls" checks whether a file is a symbolic link before calling readlink, while "eza" does not perform this check. (ls as 0 calls)

getcwd

eza calls the getcwd syscall 677 times, for every file instead of caching it. (ls as 0 calls)

statx

eza calls the statx syscall 678 times ,even when it does not need the file stats, which unnecessary. It is not printing, then why call ? (ls as 0 calls)

write

eza writes file individually, without using any buffering

Summary

ls takes 72 syscall and 0.000422 seconds. eza needs 4903 syscall and 0.029659 seconds.
readlink , getcwd , statx, write takes around 4700 syscall.

eza takes 70 times more syscalls and time

[MartinFillon]

Gonna have a look at this. I think you are raising a big point

[MartinFillon]

Well I took a look for statx, calls and readlink calls, so the two are linked as we used symlink_metadata, and we kinda take all the metadata whatever happens.

[PThorpe92]

I'm super curious why the original author never attempted to use at least buffered writes. There are comments about difficulties caching fs data/metadata. But either way I'm definitely interested in optimizing some of these things.

Thanks for bringing this up :+1:

[MartinFillon]

Well I took a look at how we could optimize this. And tbh I think that we need to rewrite about a third of the codebase

[lsproule]

I was also about to make a similar issue. I think that this would be a worthwhile improvement for sure. I mean in time I am sure it can be done