oh-my-posh is slow in Windows bash Environment (mingw64/git bash) #3787
Replies: 5 comments 11 replies
-
|
@fantasydr this has to be something else blocking the execution as I can't reproduce this at all, nor has this been reported before (and there's a lot of people using git bash unfortunately).
The command itself:
|
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your prompt response. I've inspected my environment and found nothing unusual, as PowerShell integration functions perfectly. Except the 'get millis' command, the 'print' command is also slow, taking 110ms to complete when executed directly in PowerShell. I presume oh-my-posh integration doesn't use this command for every PowerShell command, only during initialization. However, in bash, the 'print' command is called for each command, significantly slowing down the bash shell: Everything is stored on an SSD, so I'm confident that disk I/O is not the issue. Since you can't reproduce this problem in your bash environment, I will investigate what is causing the slowdown in 'oh-my-posh.exe' execution on my machine. Thank you again for this software! I will share my findings if I discover anything. |
Beta Was this translation helpful? Give feedback.
-
|
I tried to time the command on two of my computers (windows10/m.2 SSD/no virus scanner/AMD 3900x and 3700x with 32G mem)
Other executable works fine: This is so weird... |
Beta Was this translation helpful? Give feedback.
-
|
@fantasydr the print command is executed equally on PowerShell and bash, even more in PowerShell when using a transient prompt. I'm pretty sure something is slowing down execution. And for the record, I'm not saying this isn't a possible bug, but I do want to rule out any known suspects and I need a reproducible scenario. |
Beta Was this translation helpful? Give feedback.
-
|
I believe I've found the root cause. I ran a Go benchmark and identified a file reading method that loads a cache file: Somehow, this file is 3.5MB on my machine. I started using oh-my-posh just yesterday, and I've only tried it in PowerShell 5 and PowerShell 7.3. I'm unsure how the cache file grew so large. I could upload a sample if you're interested, but it contains many of my local file paths. After deleting the file and running oh-my-posh again, the cache regenerated at 9KB initially but continued to grow. I think there are two potential issues:
|
Beta Was this translation helpful? Give feedback.
-
|
@fantasydr can you let me know which keys in the cache is being populated? Or which of those keys contains a lot of data? |
Beta Was this translation helpful? Give feedback.
-
|
There are about 300 keys name "template_cache_xxxx", each of them are very big because it stored all my environments variables inside it. The environment string is large because I have many development tools installed, and all path strings are escaped, making them even longer. With 95 environment variables, I believe this is a typical case. I also think storing cache in a file and loading it every time the executable is invoked is not a common caching strategy. If the executable file is in a service and stay in memory, this might be faster than recalculating the string. However, since users need to unload and reload the exe file, a file cache could take more time than recalculating the prompt string (load/parsing/query...) |
Beta Was this translation helpful? Give feedback.
-
|
@fantasydr the executable is started every time the prompt needs to draw, it's not a continuous process so storing in memory won't work. I'll have a look at if we can improve something here, this is the first time ever this occurs and for the record, PowerShell also loads that file every time. Maybe something is off in bash though as it should only create that file per shell instance and short lived, so 300 entries without 300 bash instances would imply it generates a new key per prompt invocation. |
Beta Was this translation helpful? Give feedback.
-
|
I apologize for my previous mistake. I initially tested it in PowerShell, and I believe the cache had just been created, which made it faster, leading me to think that everything worked fine in PowerShell. However, as the cache grew larger, I only ran a few commands in PowerShell. The --execution-time parameter didn't account for oh-my-posh's execution time, so the output was always close to '0ms' because PowerShell doesn't use 'get millis' to calculate the script execution time. I modified the script to include oh-my-posh's execution time in the calculation. The results for both bash and PowerShell are shown below: I also built a version without any cache file loading/saving. The results were similar when the cache file was small, but performance slowed as the cache file grew larger. With a 3MB cache, the actual result in bash is about 220ms for the echo command and 150ms if 'get millis' is omitted. In PowerShell, the actual result is about 110ms for the echo command. Therefore, I think it's worth optimizing bash by removing the 'get millis' function. As for the cache file, a small one won't pose a significant problem, but a larger cache will still negatively impact performance. |
Beta Was this translation helpful? Give feedback.
-
|
@fantasydr first improvement #3793 |
Beta Was this translation helpful? Give feedback.
-
|
@fantasydr does this fix already improve the issue you're facing? |
Beta Was this translation helpful? Give feedback.
-
|
I apologize for the delayed response. I just built a version from the source code, and the cost of each "get millis" execution is significantly better with a larger cache file. However, the root issue is that every time I open a new tab in Windows Terminal, the cache file grows larger. I tried cleaning up my environment and removing duplicate variables, but saving the entire environment to cache is still expensive. For instance, when I export the variables into a plain text file using 'set > vars.txt', the base environment is 4KB. But after entering the Visual Studio 2019 prompt environment, it grows to 12KB. The 3MB cache file contains 300+ template_cache_pid entries. I'm not sure how the cache file is supposed to shrink since oh-my-posh doesn't know when a process closes, but it can certainly check, as the PID is saved. Perhaps it could limit the number of cached values to 'N' to ensure the cache doesn't become too large and let user set the 'N' value. Regardless, I've built a version without the cache file, and the speed is acceptable in my environment. There's no noticeable difference in performance with or without the cache. Perhaps the cache only improves performance for very complex prompt templates, and in my cases, it isn't a speed booster. Is it possible to enable cache only for particularly resource-intensive operations? Or let user decide whether use persistent file cache. In summary, there may still be two issues regarding the cache:
Thanks again for the fix, and this software has definitely been a game-changer for me. It inspired me to switch to PowerShell. Previously, I only used Bash in Windows, as the PowerShell prompt seemed dull and uninformative. Now, I can finally find the values in the prompt, making it a much better experience. |
Beta Was this translation helpful? Give feedback.
-
|
A quick thought for a possible solution about the cache/template. Add a EnableCache boolean in the template setting, only use file cache if it is true. Then let user decide whether to enable it. For small templates, set it to false. Not sure whether it is already implemented, just my two cents. |
Beta Was this translation helpful? Give feedback.
-
@fantasydr every cache entry has a TTL. The cache exists to have the same context in a transient prompt as you want to have the exact same segment data as before. A new change also only stores this when you HAVE a transient prompt set and I will also exclude the env from it as that data doesn't need to be stored for the Transient run as it's identical to what you had on ENTER. |
Beta Was this translation helpful? Give feedback.
-
Code of Conduct
What happened?
I'm using git bash together with oh-my-posh, a simple 'echo hello' command taks 100ms to finish.
I've checked the script generated by oh-my-posh hook, the most expensive call is the one in _omp_start_timer():
oh-my-posh.exe get millisIt takes almost 50~80ms to finish, and to get the $omp_elapsed value, the script need to execute it twice.
The total time will be 100ms+other cost.
A possible solution could be use date and cut in the shell script to get the time.
The Windows Virus Protection is disabled while testing. This issue only happened in git-bash. Powershell works totally fine. I guess the powershell hook does not use this method to get the elapsed time.
A demo for this timer in powershell:
A demo of how slow it can be in bash:
Theme
I think this is not related to theme, the same theme works fine in Powershell.
Any theme can reproduce this issue, I tested it on this simple theme.
{
"$schema": "https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/main/themes/schema.json",
"blocks": [
{
"alignment": "left",
"segments": [
{
"foreground": "#0CA0D8",
"style": "plain",
"template": "",
"type": "path"
}
],
"type": "prompt"
}
],
"version": 2
}
What OS are you seeing the problem on?
Windows
Which shell are you using?
bash
Log output
Beta Was this translation helpful? Give feedback.
All reactions