gitbutlerapp
Improve performance when working programmes which hold long locks
Ref: https://discord.com/channels/1060193121130000425/1240665967973892187/1242072372916260864
A user reported an issue where they were getting incredibly poor performance when working in a Unity project. It seems like unity will hold a lock on certain scene files for a very long time. This appears to cause problems with our hunk allocation code.
In this particular case, it doesn't appear that the FS watching is the issue, and the User only had a handful of changes.
It seems like this poor performance also caused the user to loose work when making a commit. It would be worth investigating whether this was caused by creating a commit while list_virtual_branches (and friends) are running
Ref: https://discord.com/channels/1060193121130000425/1204524097241878629/1242718433112752269
Good Morning, a little update, disabling burst didn't do good, when ever i started working, i launched butler and all of the changes and branches were working fine and the tracking is fast, then i closed butler for a long while edited some scripts then relaunched it, and behold the issue came back 😂 so i looked into the logs and i found an interesting new errors:
Caused by: 0: failed to lock file '"Repo Path"/.git/HEAD.lock' for writing: ; class=Os (2); code=Locked (-14) 1: failed to set head 2: failed to lock file '"Repo Path"/.git/HEAD.lock' for writing: ; class=Os (2); code=Locked (-14) event=ProjectFileChange(38b55967-b158-4a25-9b46-6a1a05d4d50d, ProjectSettings)
Error 2 might be related to the ProjectSettings.asset that was causing errors earlier. The state of butler now is infinite loading on startup, will update you if there are any new findings
Edit: Can VS code Source Control interfere with Butler? because vs code also monitor the changes in the repo Edit 2: It's been an hour and still stuck at the infinite loading thing
My feeling here is that the file watcher triggers an operation which should be read-only, but isn't. Then the operation changes some Git state, maybe it fails doing so, just to retrigger itself. In theory that should be pretty clear from the logs which would show a lot of activity.
@Byron "In theory that should be pretty clear from the logs which would show a lot of activity" You're pretty right, I've attached the log:
Thanks a lot! I took a look at the lock and fortunately do not see signs of a loop due to filesystem events. A lot happens, and there is plenty of errors around not being able to read a particular file, but also at least one occurrence of git2 being unable to change the GitButler integration ref (failed to lock file '"ProjectLocation"/.git/refs/heads/gitbutler/integration.lock').
One more question to ask would be if this is an issue on Windows?
The state of butler now is infinite loading on startup, will update you if there are any new findings
In that realm there was some improvement via #3865 so one might hope there were related. See also #2657 for a tracking issue related to infinite loading.
Thank you for the reply, yes the issue is on Windows, here are the device specifics "Home 22631.3593, 16gb 4800mhz ram, i7-12650 and an NVMe storage"