@alba4k I just found this. Great project! I compared the performance of albafetch with fastfetch in Fedora Linux, and found that albafetch costs about 400 ms while fastfetch costs about 34ms

$ hyperfine -w3 ./albafetch ~/fastfetch/build/fastfetch
Benchmark 1: ./albafetch
  Time (mean ± σ):     405.4 ms ±   2.9 ms    [User: 373.9 ms, System: 32.2 ms]
  Range (min … max):   399.6 ms … 409.8 ms    10 runs
 
Benchmark 2: /home/carter/fastfetch/build/fastfetch
  Time (mean ± σ):      34.3 ms ±   1.7 ms    [User: 21.1 ms, System: 12.6 ms]
  Range (min … max):    31.2 ms …  39.2 ms    85 runs
 
Summary
  /home/carter/fastfetch/build/fastfetch ran
   11.82 ± 0.60 times faster than ./albafetch

debug shows that the bottleneck comes from packages. albafetch uses raw rpm command which is very slow. I suggest that you should query the sqlite database used by rpm directly. The following patch does the trick:

diff --git a/src/info.c b/src/info.c
index 8d11ec9..28def2e 100644
--- a/src/info.c
+++ b/src/info.c
@@ -424,7 +424,7 @@ int packages(char *dest) {
         path[0] = 0;
         if(getenv("PREFIX"))
             strncpy(path, getenv("PREFIX"), 255);
-        strncat(path, "/bin/rpm", 256-strlen(path));
+        strncat(path, "/var/lib/rpm/rpmdb.sqlite", 256-strlen(path));
         if(pkg_rpm && !access(path, F_OK)) {
             if(pipe(pipes))
                 return 1;
@@ -433,7 +433,7 @@ int packages(char *dest) {
                 close(pipes[0]);
                 dup2(pipes[1], STDOUT_FILENO);
 
-                execlp("sh", "sh", "-c", "rpm -qa 2>/dev/null | wc -l", NULL); 
+                execlp("sh", "sh", "-c", "sqlite3 /var/lib/rpm/rpmdb.sqlite 'SELECT count(*) FROM Packages' 2>/dev/null", NULL);
             }
             wait(0);
             close(pipes[1]);

albafetch costs about 27ms with the patch applied, which is even faster than fastfetch, really impressive!

@alba4k I think I was searching for Neofetch alternatives on the AUR 🥸

albafetch is nice too, keep it up!

You could just use --ds-force-drm in chroot, and this flag will skip the X11 connection.

I’m closing this

CC @LinusDierheimer

Please make sure you are building fastfetch in Release mode

Not sure what “release mode” is, I compiled fastfetch following the README instructions:

mkdir -p build
cd build
cmake ..
cmake --build . --target fastfetch --target flashfetch

I guess it’s fine? I can see aa49877 from the dev branch in git log.

Without any config file

• From main system:

NO_DEBUG=1 ./fastfetch -s display --pipe --thread false --show-errors
Display (DP-0): 2560x1440 @ 165Hz

• From chroot:

NO_DEBUG=1 ./fastfetch -s display --pipe --thread false --show-errors
Display: Couldn't detect display

Also from chroot and with my config file:

# ~/.config/fastfetch/config.conf
--structure Title:Separator:OS:Kernel:Uptime:Packages:Shell:Display:DE:WM:Terminal:CPU:GPU:Memory:Battery:PowerAdapter:Break:Colors
--separator-string "━"
--percent-type 3

Only the following elements are printed:

• Shell
• Terminal
• CPU
• GPU
• Memory
• Colors

The following elements aren’t printed:

• Logo
• Title
• Separator
• OS
• Kernel
• Uptime
• Packages
• Display
• DE/WM (normal I guess, isn’t printed with 1.12.2 either)

On host (with the same config), Packages is missing too.

With 1.12.2 binary, these elements are printed correctly (albeit the error initially reported of course)

Oh, I think that’s because DisplayServer is run in a separated thread, and swallowed the output from normal module.

Please try fastfetch --thread false

How many *fetch programs did you install 😆

I assume that they didn’t get the same error because they didn’t try to connect x11 server. Do they support refresh rate detection?

I can add a flag to force display detection to use /sys/class/drm/