slow startup

[muellerto]

On some systems it seems to start very slow. On Windows it can take about 30s until you see something.

• show at least a startup message and then begin this time consuming action but don't let the user get the impression the app is hanging endlessly
• do this action in background (I mean: in a background thread), show the files and let the user already navigate, turn a wheel in a corner to show something is going on, you could also change the prompt while this action is still running

[leo-arch]

Hi @muellerto. Thanks for submitting these reports.

My first question is: how did you get clifm compiled on MinGW?

Last night, after reading your email, I tried to install MinGW and compile clifm, with no success. On my behalf, I never used MinGW before (and I was too sleepy to think clearly). So, good first hand instructions would be nice. Before attempting to solve any of these issues (specially those environment related, like this one), I need to reproduce them. Otherwise, I'd be working blindly.

[muellerto]

My first question is: how did you get clifm compiled on MinGW?

:)

That's not easy because of the several distributions and forks of MinGW which is about 20 years now. There's MinGW, MinGW-w64, MSYS and MSYS2. MSYS and MSYS2 are collections of UNIX-tools which include MinGW.

I recommend to download MSYS2 here:

https://www.msys2.org/

You can install it anywhere, it must not be in c:\

The main advantage of this tool set compared to the others is it's excellent pacman integration with own repositories. Perhaps you are familiar with Arch Linux, then you know pacman and it's reliability very well.

After MSYS2 has been installed you need gcc. So you type

pacman -S gcc

This installs gcc 12 or so. Or do you use clang? You can also install gdb this way, nano, vim, emacs, git ...

There's also libreadline. Be sure to use the devel package (libreadline-devel) to get the headers.

fzf is special, the package has multiple names here. Try

pacman -Ss fzf

to get them listed.

I installed mingw-w64-ucrt-x86_64-fzf. After this has been done the binary of fzf has then also this weird name, mingw-w64-ucrt-x86_64-fzf. I made a symbolic link named fzf into the MSYS /usr/bin, this works very well.

I can't remember if there's a make in MSYS by default. The make tool I use has the package name mingw-w64-x86_64-make, this is just GNU make.

With this environment I tried compiling clifm using the included Cygwin Makefile as mentioned in the documentation and it succeeded in the first try without a single warning. I almost couldn't believe that.

[muellerto]

And you will surely need ConEmu.

[leo-arch]

I'll give it a try as soon as I can. Thanks for the detailed explanation!

[leo-arch]

Got it working. Just needed to add gettext-devel package to your install instructions.
Now I can start debugging the issues you pointed out.

[leo-arch]

Well, the thing is that clifm keeps a record of binary files in PATH to easily have them available for the completions/suggestions system (maybe this approach is flawed from the beginning, but that's another story). Now, since a non-native environment populates its PATH with lot of binaries (like dll's), which are not supposed to be there in a native environment, this is what makes clifm slow to start.

Proof of concept

Run with the -x switch: clifm starts immediately, because external binaries (i.e. shell commands) are totally disabled.

Workaround

Disabling external commands however is probably not what you want. So, a better approach would be to limit the amount of binaries scanned to only those you actually need (mostly Unix applications) by setting a custom PATH variable holding only the paths to these binaries. For example:

PATH="/usr/local/bin:/usr/bin" clifm

Though far from ideal, this should boost startup time considerably.

[muellerto]

Yes, I have a loooooong PATH variable containing 27 parts, including all the crap Microsoft SQL Server wants to have in the PATH.

I'm not sure what files you really search (I didn't inspect your code until now) but DLLs should not disturb regardless of how many there are. On Windows you should not evaluate any x-bit a library function returns (that's not serious, the bit doesn't exist in the file system) - instead you must really search just for .exe, .bat and .cmd files only. There should not be a single other file in the PATH being executable or usable in a completion.

And there's still another special on Windows: the current directory must always be implicit on top of the PATH. Executables in the current directory must also be found.

[leo-arch]

Code refactored: it should be much faster now. Give it a try.

[muellerto]

Yeah, great. This seems to be much better, I achieve about 3s now, factor 10! Think we can close this case.