Repository navigation
[BUG] ghostty detection is slow (not fast) #2122
Description
Read the FAQ first
- I have checked the FAQ but the issue is not covered
Description
I was running fastfetch on terminal startup (e.g. in shell startup file) and noticed it seemed a bit slow, and I've narrowed it down (using fastfetch --stat) to the terminal and terminal font modules.
Expected: detecting terminal and its font is similar speed to other modules (e.g. less than 10ms).
Observed: it takes over 100ms.
Example:
Steps to reproduce:
- Use ghostty terminal.
- Run
fastfetch --stat - Optionally, for debugging, use the simplified config (in ~/.config/fastfetch/config.jsonc) (attached below).
- Observer timings.
Version used
fastfetch 2.56.1 (x86_64)
Bug prevalence
Always
Regression
Not sure
Installation
Package manager
Package manager
brew
Screenshots
No response
Configuration
{
"$schema": "https://github.com/fastfetch-cli/fastfetch/raw/master/doc/json_schema.json",
"display": {
"stat": false,
"pipe": false,
"showErrors": false,
"disableLinewrap": true,
"hideCursor": false,
"separator": ": ",
"color": {
"keys": "",
"title": "",
"output": "",
"separator": ""
},
"brightColor": true,
"duration": {
"abbreviation": false,
"spaceBeforeUnit": "default"
},
"size": {
"maxPrefix": "YB",
"binaryPrefix": "iec",
"ndigits": 2,
"spaceBeforeUnit": "default"
},
"temp": {
"unit": "D",
"ndigits": 1,
"color": {
"green": "32",
"yellow": "93",
"red": "91"
},
"spaceBeforeUnit": "default"
},
"percent": {
"type": [
"num",
"num-color"
],
"ndigits": 0,
"color": {
"green": "32",
"yellow": "93",
"red": "91"
},
"spaceBeforeUnit": "default",
"width": 0
},
"bar": {
"char": {
"elapsed": "■",
"total": "-"
},
"border": {
"left": "[ ",
"right": " ]",
"leftElapsed": "",
"rightElapsed": ""
},
"color": {
"elapsed": "auto",
"total": "97",
"border": "97"
},
"width": 10
},
"fraction": {
"ndigits": 2
},
"noBuffer": false,
"key": {
"width": 0,
"type": "string",
"paddingLeft": 0
},
"freq": {
"ndigits": 2,
"spaceBeforeUnit": "default"
},
"constants": []
},
"general": {
"thread": true,
"processingTimeout": 5000,
"detectVersion": true
},
"modules": [
"break",
{
"type": "terminal",
"keyIcon": ""
},
{
"type": "terminalfont",
"keyIcon": ""
},
"break",
{
"type": "colors",
"key": " ",
"keyIcon": "",
"symbol": "block",
"paddingLeft": 0,
"block": {
"width": 3,
"range": [
0,
15
]
}
}
]
}System information
Probably unrelevant, seems issue stems from exec'ing ghostty (based on this part of the code).
Features built-in
threads
vulkan
imagemagick7
chafa
zlib
sqlite3
libzfs
System yyjson
Activity
CarterLi commentedon Jan 1, 2026
You are correct. The problem is that ghostty config files can be complex. See #1972
clicelee commentedon Jul 12, 2026
The cost here is spawning the ghostty binary itself. +show-config initializes the full app config machinery before printing anything, which is why the module takes 100ms+ while most others finish in under 10ms.
Since fastfetch only needs font-family and font-size, would you accept a PR that returns to static config file parsing, but this time following config-file directives recursively? That is:
That would fix the detection failures that motivated replacing the old implementation in de92296 (ref #1972), while keeping the module fast (pure file I/O, no exec).
If you'd rather keep +show-config as the source of truth, an alternative would be a hybrid: parse statically first, and only fall back to exec'ing ghostty when the config actually contains config-file directives. Happy to implement either. I'd lean toward the first.
TerminalFont (Ghostty): parse config files statically instead of exec…