Gittyup
Gittyup copied to clipboard
Murmele
huge ram and cpu consumption
Ok so this will be probably my worst issue because i cannot tell anyting about the project =/
frequently on big project (labview here), gittyup takes a stupid ammount of ram and cpu and sometime crashes
for cpu i am over 60% on a intel i7 and use more than 3g of ram (the full project with git folder is about 2gb)
it look like the stagging area is a source of a lot of these errors
Hi @moolight-seashell thanks for the report. Do you have an example file which creates this issue?
i am trying to to isolate and extract the problem, but but it's neither very clear nor simple to me. I guarantee nothing
maybe this is liked to https://github.com/Murmele/Gittyup/issues/566
in labview, .vi files contain both source code and compiled code, and are saved in the proprietary .vi format, which is a binary file. When you make a modification to a project, labviw tends to recompile everything on its own (because it has an on-the-fly compiling system). So from a git point of view, almost all the files have been modified, whereas you only want to add a few to the commit.
the project is about 2bg of binary file
This is definitely the biggest issue with the program.
It freezes for several (~5?) minutes sometimes, with 100% usage of CPU core.
No big binary files necessary in my testing - all files are under 4MB. It's not even a repo with a very long history - a rather modest history.
Ah, I just found an easy way to reproduce it. I use QtCreator, which creates a .qtc_clangd directory, which in this case is 105MB, but it trips up Gittyup. Create a QtCreator project for a C++ repo, and ensure clangd is enabled, so that the .qtc_clangd is enabled. Open your repo in Gittyup, and clicking refresh is also pretty intensive if you want it to happen again.
Therefore, a workaround is to add .qtc_clangd/** to the .gitignore file (which I was sometimes lazy to do).
It would be nice if it could handle this nonetheless.
@sammyj85 thanks for the investigation :) the gui probably does not freeze for a few minutes, but freezes all the time this folder is modified. A change will trigger Gittyup to refresh.
I tried using gittyup with a private repo. On opening of a repo, one core CPU usage goes to 100%. Every time I press on another changeset in the list to select it, another thread appears taking an additional core to 100%. Once I hit my number of cores(12), it does not seem to spawn any more tasks but instead the UI locks up. I can't provide you the repo so I can't readily supply a way to reproduce. I tried compiling latest master myself then same issue using flatpak on Ubuntu.
