Closed CarterLi closed 2 months ago
In order to make your benchmark result reproduceable, you should provide the config file you use.
Using the following configs on the latest git release;
My host machine remains faster;
However both my VM's, FastFetch is faster;
Working on figuring out what's bottlenecking and why, I'm suspecting file IO particularly on GPU but not sure yet. Will get back to you with a more definitive answer soon. I'm also aware these are VM's and are likely un-trusted, so also gonna start testing on live-boots with my laptop later.
And will also update benchmarks on the README once I can too. Was already planning a Benchmarks wiki page so can put full nerdy details there.
crabfetch doesn't support EndeavourOS logo. It should fall back to its upstream distro Archlinux, or display a general Linux logo. However crabfetch left it empty.
CrabFetch only gets distro ASCII's from the data in /etc/os-release
and hasn't implemented EndeavourOS. I'm already in-progress of getting a full list of distros and going through them one by one to add support, as I agree CrabFetch's OS support is kinda shitty.
crabfetch detects my NVIDIA discrete GPU has 0 KB VMEM. It's definitely wrong.
I don't have any NVIDIA GPU's to work with right now, so can't troubleshoot this right now. Will see if I can nick a mate's PC and live boot into it to fix.
crabfetch shows useless partitions. Notably the tmpfs.
This is why the ignore
config option exists, will also adapt it to allow ignoring specific filesystems now that 0.4.0 gets that info.
pacman packages count is wrong.
CrabFetch isn't filtering the ALPM_DB_VERSION
file out, causing it to be off by one. Will also fix this later today when I have time to actually get work done.
crabfetch fails to detect the media played in Chrome.
CrabFetch will only listen to one player, and won't bother detecting which one is currently in use as to prevent it wasting time requesting the status of each player when most people only use one. Make sure your setting the player in your CrabFetch config correctly, not sure what Chrome uses so you'll have to go probing in a dbus viewer.
Fedora Live Boot on an actual machine and CrabFetch is still faster. Only my VMs are failing, which makes sense given IO on most VMs is dogshit unless you set it up correctly (which I don't know how to do).
On your failing machine can you run crabfetch --benchmark
and send the output so I can see what's taking the most time? If FastFetch has a similar kind of option could I get that too.
Will also make an EndeavourOS USB (Also going to finally use Ventoy like a good developer) and will test on there, although I imagine the results will likely be the same.
Endeavour Live Boot still not able to replicate, defo need that benchmark output to help you further
[Benchmark] Args Parsing: 213.27µs
[Benchmark] Parsing Config: 586.727µs
[Benchmark] OS Pre-Module: 62.728µs
[Benchmark] ASCII (Potentially includes OS parse): 75.077µs
[Benchmark] Mounts Module (Pre-comp for max_title_length): 167.636µs
[Benchmark] Displays Module (Pre-comp for max_title_length): 5.668549ms
[Benchmark] Hostname Module: 38.233µs
[Benchmark] Entire Module Parse/Detection: 42.426µs
[Benchmark] Underline Module: 1.225µs
[Benchmark] Entire Module Parse/Detection: 5.564µs
[Benchmark] CPU Module: 436.204µs
[Benchmark] Entire Module Parse/Detection: 438.844µs
[Benchmark] GPU Module: 8.060852ms
[Benchmark] Entire Module Parse/Detection: 8.072341ms
[Benchmark] Memory Module: 35.376µs
[Benchmark] Entire Module Parse/Detection: 38.33µs
[Benchmark] Swap Module: 16.335µs
[Benchmark] Entire Module Parse/Detection: 18.229µs
[Benchmark] Mounts Module: 35.078µs
[Benchmark] Entire Module Parse/Detection: 38.436µs
[Benchmark] Host Module: 17.373µs
[Benchmark] Entire Module Parse/Detection: 19.578µs
[Benchmark] Displays Module: 7µs
[Benchmark] Entire Module Parse/Detection: 8.742µs
[Benchmark] OS Module: 3.862µs
[Benchmark] Entire Module Parse/Detection: 5.273µs
[Benchmark] Packages Module: 411.597µs
[Benchmark] Entire Module Parse/Detection: 416.342µs
[Benchmark] Desktop Module: 5.897µs
[Benchmark] Entire Module Parse/Detection: 9.062µs
[Benchmark] Terminal Module: 47.011µs
[Benchmark] Entire Module Parse/Detection: 49.86µs
[Benchmark] Shell Module: 15.895µs
[Benchmark] Entire Module Parse/Detection: 18.603µs
[Benchmark] Editor Module: 4.765µs
[Benchmark] Entire Module Parse/Detection: 7.672µs
[Benchmark] Uptime Module: 24.081µs
[Benchmark] Entire Module Parse/Detection: 26.603µs
[Benchmark] Locale Module: 4.726µs
[Benchmark] Entire Module Parse/Detection: 7.315µs
[Benchmark] Music Module: 1.074304ms
[Benchmark] Entire Module Parse/Detection: 1.096017ms
[Benchmark] InitSys Module: 46.167µs
[Benchmark] Entire Module Parse/Detection: 55.522µs
[Benchmark] Processes Module: 923.145µs
[Benchmark] Entire Module Parse/Detection: 938.078µs
[Benchmark] Space Module: 362ns
[Benchmark] Entire Module Parse/Detection: 4.355µs
[Benchmark] Colors Module: 9.01µs
[Benchmark] Entire Module Parse/Detection: 13.215µs
[Benchmark] Bright Colors Module: 6.816µs
[Benchmark] Entire Module Parse/Detection: 10.267µs
[Benchmark] Entire detection step: 11.393789ms
[Benchmark] Display ASCII Pre-Calc: 594ns
carter@carter_endeavouros_local
――――――――――――――――
CPU > 12th Gen Intel(R) Core(TM) i7-12700H (14c 20t) @ 4.6 GHz
GPU > NVIDIA Corporation GA104 [Geforce RTX 3070 Ti Laptop GPU] (0 KB)
GPU > Intel Corporation Alder Lake-P GT2 [Iris Xe Graphics] (0 KB)
Memory > 4.06 GB / 33.34 GB (12.17%)
Swap > 0.00 KB / 0.00 KB (0%)
Disk (/) > 12 GB used of 52.64 GB (21.87%) [btrfs]
Disk (/home) > 12 GB used of 52.64 GB (21.87%) [btrfs]
Disk (/var/cache) > 12 GB used of 52.64 GB (21.87%) [btrfs]
Disk (/var/log) > 12 GB used of 52.64 GB (21.87%) [btrfs]
Host > Raider GE76 12UGS
Display (eDP-2) > 2560x1440 @ 240Hz
Operating System > EndeavourOS (6.9.8-arch1-1)
Packages > 1055 (pacman)
Desktop > KDE (wayland)
Terminal > konsole
Shell > fish
Editor > NeoVim
Uptime > 20m 29s
Locale > zh_CN (UTF-8)
Music > Unknown
Init System > systemd
Total Processes > 392
[Benchmark] Module + ASCII Output: 131.295µs
[Benchmark] Remaining ASCII Output: 76ns
fastfetch supports similar flag --stat
Noticed that the frequency detection was wrong. According to Intel spec the maximum frequency is 4.7 GHz: https://www.intel.com/content/www/us/en/products/sku/132228/intel-core-i712700h-processor-24m-cache-up-to-4-70-ghz/specifications.html
Only my VMs are failing, which makes sense given IO on most VMs is dogshit...
It doesn't make sense, because fastfetch and crabfetch run on the same VM. In addition, bad IO benefits crabfetch because fastfetch supports a lot more package manager detection and checks more directories despite most of them don't exist.
I don't want you to replicate my benchmark result. It makes sense to get different result with different hardwares. I want you to make the benchmark fair for fastfetch. Also you should provide the configuration of fastfetch you used when benchmarking. If you use my config file, --detect-version false
should not be necessary.
Also you should have these bug fixed before roaring crabfetch is fastest and other fetches are shit
Your --benchmark
results have me stumped lol. Your compositor's taking 5ms to give me display details but that's fine, out of my control anyway. Your GPU taking 8ms I have no idea how you've done though. Will defo have to get access to a NVIDIA/Intel system and figure it out cus that's a really bad look.
Noticed that the frequency detection was wrong. According to Intel spec the maximum frequency is 4.7 GHz: https://www.intel.com/content/www/us/en/products/sku/132228/intel-core-i712700h-processor-24m-cache-up-to-4-70-ghz/specifications.html
Here's the sources for that if you wanna go investigate, again don't a Intel CPU, it's not happening on mine and I don't have access to your system so you'll have to go hunting to help me here;
I'm guessing it's not doing it's backup to current CPU speed as it's remaining consistently at 4.6GHz in both your results.
Only my VMs are failing, which makes sense given IO on most VMs is dogshit...
It doesn't make sense, because fastfetch and crabfetch run on the same VM. In addition, bad IO benefits crabfetch because fastfetch supports a lot more package manager detection and checks more directories despite most of them don't exist.
Ye this makes sense, confuses me even more but does make sense opposed to my random guess from the top of my head. Added to my list of stuff to do.
I don't want you to replicate my benchmark result. It makes sense to get different result with different hardwares. I want you to make the benchmark fair for fastfetch. Also you should provide the configuration of fastfetch you used when benchmarking. If you use my config file,
--detect-version false
should not be necessary.
You don't but I do, as it means there's a problem with my coding somewhere. I also did post my configs, although didn't include the detectVersion variable in it. I'll do it for future benchmarks but it shouldn't make a major difference to the benchmarks unless your config parsing is that performance sensitive (which it isn't).
I already plan to update my benchmarks on this repo later tonight, don't worry.
Also you should have these bug fixed before roaring
crabfetch is fastest and other fetches are shit
I've pointed this out to you before and I'll point it out to you again; I do not claim CrabFetch to be stable software. I'm very much still actively developing it and growing on it, I'm aware it's broken in a lot of places and I'm aware it's more juvenile in it's detection methods. This is a project I'm using to learn Rust (coming from what was essentially game modding and web development), while also fixing a problem I had personally. Obviously I want it to be better, and that's why it's publicly shared and I'm actually trying to put time into it, so that people can help me improve it and learn lower level development faster (something you have contributed to, so thanks :) ) Also, I don't claim anywhere on this GitHub that I'm aware of that CrabFetch is the fastest, and if I do please let me know where so I can remove it. I used to advertise this, yes, however have since learned to not make such bold statements without a damn good backing up for it. I now try to aim for it to be the fastest, but also now know it's not as simple as that and merely front-page my benchmarks as a "this is what I'm aiming for, if it doesn't help me fix it".
Updated the README with more recent benchmark results as well as a wiki page with more in-depth and technical benchmarks.
It was still unfair for fastfetch. You still ignored the fact that fastfetch detects more information and is easier to use. For example:
All of these features take time
Correct me if I'm wrong, I don't know how FastFetch internally works, but even if I was to modify my FastFetch config to remove these, you would be still fetching this in the background as a part of the whole module, so it wouldn't make a difference to performance benchmarks regardless?
If so, then I'm not too sure what your expecting me to do right now, as I'll also need time to research and add these features myself to match up to you. I'll also add that I am indeed omitting some ease of use such as music player detection... so that I'm not wasting performance time, meaning CrabFetch would indeed be faster.
I'm sorry if I'm not giving you the response your looking for, but I honestly don't know what your expecting me to do here. You've had 2-3 years of development time on your project to figure out detection methods and optimizations, I've had a few months of inexperience in a new language.
I want you to metion these comments in your wiki. Thanks
I want you to metion these comments in your wiki. Thanks
No, this isn't a FastFetch marketing GitHub page.
As #13 is not implemented, the benchmark is unfair for fastfetch because version detection requires expensive interprocess communication in most cases.
Fastfetch implemented a flag for your benchmark called
detectVersion
( requires v2.18.1 ). This is the config file I use:My result:
Also some comments:
Compare to fastfetch