Unreplicateable benchmark result

[CarterLi]

Describe the bug

$ hyperfine "~/fastfetch/build/fastfetch -c none -s 'title:separator:cpu:gpu:memory:swap:disk:host:display:os:kernel:packages:de:terminal:shell:uptime:break:colors' --pipe false" "./crabfetch"
Benchmark 1: ~/fastfetch/build/fastfetch -c none -s 'title:separator:cpu:gpu:memory:swap:disk:host:display:os:kernel:packages:de:terminal:shell:uptime:break:colors' --pipe false
  Time (mean ± σ):      17.8 ms ±   5.9 ms    [User: 3.1 ms, System: 8.4 ms]
  Range (min … max):     8.8 ms …  36.8 ms    227 runs

Benchmark 2: ./crabfetch
  Time (mean ± σ):      35.9 ms ±   4.5 ms    [User: 20.1 ms, System: 10.6 ms]
  Range (min … max):    29.6 ms …  50.7 ms    78 runs

Summary
  ~/fastfetch/build/fastfetch -c none -s 'title:separator:cpu:gpu:memory:swap:disk:host:display:os:kernel:packages:de:terminal:shell:uptime:break:colors' --pipe false ran
    2.01 ± 0.71 times faster than ./crabfetch

To Reproduce Steps to reproduce the behavior:

1. hyperfine "~/fastfetch/build/fastfetch -c none -s 'title:separator:cpu:gpu:memory:swap:disk:host:display:os:kernel:packages:de:terminal:shell:uptime:break:colors' --pipe false" "./crabfetch"

Screenshots

Desktop (please complete the following information):

• Distribution: Fedora
• CrabFetch Version (crabfetch -V): 0.1.1

Additional Comments Any additional comments you may have.

1. GPU result was wrong
2. Host was wrong. It shows the name of the motherboard, instead of the marketing name of my laptop
3. Packages detects nothing
4. When uptime is less than 1h, CrabFetch shows 0h xmin...
5. If I run crabfetch in a non-default shell, it still prints my default shell

[LivacoNew]

Interesting, I can't replicate this running the same command on neither my Desktop or Laptop. Only difference I made to the command being I'm grabbing the binaries globally opposed to a specific directory. Just to confirm; I'm using fastfetch 2.9.1 from Arch's repos.

Desktop:

sam@silverhand > hyperfine "fastfetch -c none -s 'title:separator:cpu:gpu:memory:swap:disk:host:display:os:kernel:packages:de:terminal:shell:uptime:break:colors' --pipe false" "crabfetch"                                                                               ~
Benchmark 1: fastfetch -c none -s 'title:separator:cpu:gpu:memory:swap:disk:host:display:os:kernel:packages:de:terminal:shell:uptime:break:colors' --pipe false
  Time (mean ± σ):      51.5 ms ±   1.8 ms    [User: 37.4 ms, System: 13.5 ms]
  Range (min … max):    49.4 ms …  60.2 ms    56 runs

Benchmark 2: crabfetch
  Time (mean ± σ):       4.8 ms ±   0.2 ms    [User: 2.5 ms, System: 2.4 ms]
  Range (min … max):     4.5 ms …   5.7 ms    450 runs

  Warning: Command took less than 5 ms to complete. Note that the results might be inaccurate because hyperfine can not calibrate the shell startup time much more precise than this limit. You can try to use the `-N`/`--shell=none` option to disable the shell completely.

Summary
  crabfetch ran
   10.74 ± 0.63 times faster than fastfetch -c none -s 'title:separator:cpu:gpu:memory:swap:disk:host:display:os:kernel:packages:de:terminal:shell:uptime:break:colors' --pipe false
sam@silverhand >      

Laptop:

sam@songbird > hyperfine "fastfetch -c none -s 'title:separator:cpu:gpu:memory:swap:disk:host:display:os:kernel:packages:de:terminal:shell:uptime:break:colors' --pipe false" "crabfetch"                  ~
Benchmark 1: fastfetch -c none -s 'title:separator:cpu:gpu:memory:swap:disk:host:display:os:kernel:packages:de:terminal:shell:uptime:break:colors' --pipe false
  Time (mean ± σ):     110.6 ms ±   2.7 ms    [User: 84.0 ms, System: 25.2 ms]
  Range (min … max):   106.9 ms … 117.1 ms    27 runs

Benchmark 2: crabfetch
  Time (mean ± σ):       4.5 ms ±   0.3 ms    [User: 2.2 ms, System: 2.5 ms]
  Range (min … max):     3.9 ms …   6.0 ms    354 runs

  Warning: Command took less than 5 ms to complete. Note that the results might be inaccurate because hyperfine can not calibrate the shell startup time much more precise than this limit. You can try to use the `-N`/`--shell=none` option to disable the shell completely.

Summary
  crabfetch ran
   24.51 ± 1.86 times faster than fastfetch -c none -s 'title:separator:cpu:gpu:memory:swap:disk:host:display:os:kernel:packages:de:terminal:shell:uptime:break:colors' --pipe false
 sam@songbird >   

Will boot up a Fedora live ISO (assuming they provide) later onto my laptop and try again, as I can only assume this is from a difference in OS/Setup as your laptop should be way powerful than mine quickly glaring at the specs.

As for the rest w/ checkboxes to marked as fixed or not;

• [x] GPU: If you can try to find the device it's registering in lspci. From there, go to it's entry in /sys/bus/pci/devices/{BDF} and give me the class file's contents. E.g cat /sys/bus/pci/devices/0000:03:00.0/class I'm assuming your using the pcisysbus GPU method given glxinfo is unlikely to give an output like that. If that class file starts with 0x03, CrabFetch assumes it's a display adapter and uses it. Likelyhood is I've simply oversighted what a "display adapter" can be and it's picking up something that is a display adapter, but isn't a GPU. EDIT: I'm assuming this is fixed now from your PR?
• [x] Host: It grabs from dmi's board_name, so that makes sense. It gave the same output as neofetch on my desktop so I called it a day from there, not when it comes to laptops evidently. Also added to my to-do list.
• [x] Packages: I've not added dnf support yet. Support for distros and different softwares is on a "as people request it" basis as I don't have that much time to be sitting researching what distros use what. Will also get on this soon.
• [x] Uptime: Technically intended, but I agree not great. Already want to redo how it outputs to prevent this kinda stuff.
• [x] Shell: This is because CrabFetch uses whatevers in $SHELL - Will look into other detection methods as well as I kinda assumed it would update if you swapped over to another one.

[LivacoNew]

It's not OS setup by the looks of things, liveboot Fedora 39 and FastFetch is still slower...

Not too sure at this point tbh? Anything about your laptop that may be unusual or outdated?

[CarterLi]

I was able to replicate my bench result in asahilinux

The output of crabfetch was much worse here. No logo; No CPU name and the frequency output was wrong; No GPU result; duplicated disk entries; No host...

[CarterLi]

I was also to replicate the result in Github Action

Benchmark 1: ./fastfetch -c none -s 'title:separator:cpu:gpu:memory:swap:disk:host:display:os:kernel:packages:de:terminal:shell:uptime:break:colors' --packages-disabled 'APK:BREW:CHOCO:EMERGE:EOPKG:NIX:OPKG:PALUDIS:PKG:PKGTOOL:MACPORTS:RPM:SCOOP:SNAP:WINGET:XBPS:AM' --ds-force-drm --logo-separate --pipe false --show-errors
  Time (mean ± σ):       8.[5](https://github.com/CarterLi/fetch-bench/actions/runs/8701260837/job/23862912108#step:10:6) ms ±   0.3 ms    [User: 2.3 ms, System: 6.4 ms]
  Range (min … max):     8.0 ms …   9.8 ms    293 runs

Benchmark 2: ./crabfetch
  Time (mean ± σ):       9.8 ms ±   0.3 ms    [User: 5.3 ms, System: 4.[6](https://github.com/CarterLi/fetch-bench/actions/runs/8701260837/job/23862912108#step:10:7) ms]
  Range (min … max):     9.3 ms …  12.5 ms    263 runs

Summary
  './fastfetch -c none -s 'title:separator:cpu:gpu:memory:swap:disk:host:display:os:kernel:packages:de:terminal:shell:uptime:break:colors' --packages-disabled 'APK:BREW:CHOCO:EMERGE:EOPKG:NIX:OPKG:PALUDIS:PKG:PKGTOOL:MACPORTS:RPM:SCOOP:SNAP:WINGET:XBPS:AM' --ds-force-drm --logo-separate --pipe false --show-errors' ran
    1.14 ± 0.05 times faster than './crabfetch'

As shown in run hyperfine section of https://github.com/CarterLi/fetch-bench/actions/runs/8701260837/job/23862912108

The CI script: https://github.com/CarterLi/fetch-bench/blob/master/.github/workflows/ci.yml

Two notes:

1. Fastfetch supports much more package managers. As the performance of IO is much worse than a physical machine, I disabled ones that are not supported by crabfetch.
2. Github Action doesn't have a GUI environment. In this case, fastfetch tries a lot of methods to grab a result. As it's not a normal case, I disabled some of them with --ds-force-drm.

Although fastfetch detects more information (like the shell version and a lot information not shown by default in run fastfetch --format json section), it still runs faster than crabfetch.

Some bugs found in crabfetch output:

1. CPU frequency was wrong
2. GPU was wrong
3. Messy code in Terminal result
4. Failed to detect shell

[CarterLi]

Incomplete output in Arch. Seems crashed?

[LivacoNew]

Still unable to replicate any bad performance in any of my environments, CrabFetch always wins on every single environment I personally try it on. If I get desperate I'll make a separate repo and work with Github CI but if I can get an actual machine or ssh connection to work with before it comes to that I'll try every damn device I have. I'm still not sure what your environments are that's so different but I'll bloody find out one way or another. Also not entirely surprised Asahi is broken, and from what I can tell you can't VM it (if I'm wrong correct me) and I don't have a Macbook so it's support will just have to perish.

As for the rest, I've made a full list of stuff I will work on and will continue to work on it over the next few days whenever I get spare time. I'm going to re-ask you to provide that GPU info as well as to try running the commands with the --suppress-errors=false launch flag to let CrabFetch dump errors out that I can use to help debug these issues.

[CarterLi]

Just noticed that you use kscreen-doctor. This command is expensive according to my test.

Crabfetch tends to spawn 3rd-party processes for simplification while fastfetch tends to write everything manually. The latter is harder but:

1. Has no process execution and interprocess communication costs.
2. Be able to control what's needed and what isn't
3. Don't need to parse the result

The only part crabfetch can be faster is that crabfetch detects less things than fastfetch. This advantage will get smaller as crabfetch gets more features.

[CarterLi]

Code I used:

diff --git a/src/main.rs b/src/main.rs
index 77b41df..a8a1cbd 100644
--- a/src/main.rs
+++ b/src/main.rs
@@ -4,6 +4,7 @@ use config_manager::CrabFetchColor;
 use lazy_static::lazy_static;
 use clap::{ArgAction, Parser};
 use colored::{ColoredString, Colorize};
+use std::time::Instant;

 use crate::{config_manager::{color_string, Configuration}, displays::DisplayInfo, mounts::MountInfo, os::OSInfo};

@@ -143,6 +144,7 @@ fn log_error(module: &str, message: String) {

 fn main() {
+    let start = Instant::now();
     // Are we defo in Linux?
     if env::consts::OS != "linux" {
         println!("CrabFetch only supports Linux! If you want to go through and add support for your own OS, make a pull request :)");
@@ -196,6 +198,8 @@ fn main() {
     }

     let line_count = max(split.len(), module_count);
+    let duration = (Instant::now() - start).as_millis().to_string() + " ms";
+    println!("\x1b[9999999C\x1b[{}D{}", duration.len(), duration);

     for x in 0..line_count {
         let mut line = "";
@@ -221,6 +225,7 @@ fn main() {
         }

         if modules.len() > line_number as usize {
+            let start = Instant::now();
             let module_split: Vec<&str> = modules[line_number as usize].split(":").collect();
             let module: String = module_split[0].to_string();
             // print!("{}", module);
@@ -333,6 +338,8 @@ fn main() {
                     print!("Unknown module: {}", module);
                 }
             }
+            let duration = (Instant::now() - start).as_millis().to_string() + " ms";
+            print!("\x1b[9999999C\x1b[{}D{}", duration.len(), duration);
         }
         line_number = line_number + 1;

[LivacoNew]

Just noticed that you use kscreen-doctor. This command is expensive according to my test.

Crabfetch tends to spawn 3rd-party processes for simplification while fastfetch tends to write everything manually. The latter is harder but:

1. Has no process execution and interprocess communication costs.

2. Be able to control what's needed and what isn't

3. Don't need to parse the result

The only part crabfetch can be faster is that crabfetch detects less things than fastfetch. This advantage will get smaller as crabfetch gets more features.

Thank you Github for not showing me this message... This explains why I never was able to replicate, as I never tested on KDE only Hyprland and Gnome. Will reopen and look for a better way to find this info. Thanks for investigating :)

[CarterLi]

I never tested on KDE only Hyprland and Gnome

Yeah. In Gnome crabfetch is much faster because...

Display detection in Crabfetch don't even support Gnome

[LivacoNew]

Closing this as KDE performance should be better now. As for general performance it's something I'll work on over time but not something that can be closed in a single go really. From my rough testing, we're either neck and neck or CrabFetch wins, but on smaller modules FastFetch wins instead. I've already got a few ideas but again I don't see a need for an issue being open as I will be working on this over months likely.

To once again address the other issues brought up in this;

• I'm guessing the GPU was fixed in your PR, as I've still not been able to replicate it and you've not answered my questions about it.
• Host on laptops now priorities the chassis name, giving the name of the laptop.
• Non-Default Shell, Arch Crash, Gnome Displays, Uptime, Fedora packages should now fixed. If not, let me know and I'll bang my head against my keyboard a bit more.