Repository navigation
Hard CPU pressure on background. #102
Description
- Build latest master.
- Open any repo.
- Switch to code editor and edit any file from the repo with saving. GitX starts some activity that pressure all available cores.
Reacted by Robin Whittleton, Alastair Harrison, Brian Porter, Carlos Ramos, javenwang, David Bourguignon and Magnus Holm
Activity
robinwhittleton commentedon Sep 29, 2017
I’ve noticed this too, although I put it down to the fact that I had multiple 1mb unmerged epubs sitting in the repo.
beporter commentedon Oct 9, 2017
For me the CPU spikes when I start running my
phpunittest suite against the checked out repo. Bringing GitX to the front momentarily seems to resolve the issue until the next test suite run. I can usually tell this is happening because it's the only time the fan in my MacBook turns on. 😞tiennou commentedon Oct 9, 2017
Sorry, I don't remember whether something related to how GitX run command-line tasks has been merged yet or not (I think not), but if my memory isn't faulty, you guys are running with the "Automatic refresh" thingy enabled (see GitX preferences), and it can cause major issues when 1) there's major filesystem churn going on 2) you use
gitto perform rebases (because locking).It's actually best to disable it and manually refresh (⌘R) when switching to GitX.
vng commentedon Oct 11, 2017
@tiennou If you mean "Watch for changes in repositories", this option is off for me, but the problem still exists. I didn't find any other "Automatic refresh" option.
mangerlahn commentedon Dec 1, 2017
I think I found the issue.
The addition of
in 7057740 causes the CPU load. If I comment this section out, the issue is gone (for me!)..
The lines can be found in
- (void)setDataOutput:(nonnull NSMutableData *)dataOutput;ofPBEasyPipe.I don't know what the codes purpose is, but I am sure removing it is not the solution 😅
mangerlahn commentedon Dec 1, 2017
Maybe @claybridges can help?
tiennou commentedon Dec 2, 2017
Might be caused by this. Does adding
[self.fileHandleForReading closeFile]to that-clearmethod makes it go away ? I suspect there's a retain loop somewhere, which would cause the task to linger, causing the pipe to not be closed.Fix gitx#102 by closing the fileHandle
mangerlahn commentedon Dec 2, 2017
You were right! Closing the handle relaxes the situation.. Thanks!
mitisBlack commentedon Jan 29, 2018
@tiennou the fix for this is not quite correct. See the second answer on the stackoverflow link. If the file is not complete (or read completely), the sub-process will fail with a SIGPIPE abort. I can reproduce this easily when attempting to amend a patch with many changed files (eg: updated smth across all .h files in a project).
robinwhittleton commentedon Jan 29, 2018
Thanks for the diagnosis @mitisBlack. GitX has definitely been quite explosive for me since this merge. For example, I had to give up using GitX and switch to Fork to review the changes in this commit yesterday: robinwhittleton/herman-melville_moby-dick@26af223. Feel free to clone the repo and soft reset to try to replicate if you want.
tiennou commentedon Feb 5, 2018
Just pushed a fix to master for the 2nd part, and checked that the Moby Dick repo works (thanks for that @robinwhittleton, that's a pretty helpful test case 😉).