General lag, input lag, and freezing from time to time.

[RiseOoi]

This is a known past issue.

When Gitgutter is removed, Sublime works fine and smoothly. When Gitgutter is installed, Sublime becomes quite laggy.

I have uninstalled every single other packages and test it with Gitgutter only. Gitgutter is the confirmed culprit when writing long files.

I am using Sublime build 3207. I have had the non_blocking set to true and livemode to false but no improvement.

[Pictor13]

I am afraid I have the same problem. With GitGutter active, when working on a virtual machine mounted as NFS volume on my MacBook, the virtual machine is always using 50-100% of the CPU power for no apparent reason.

Sometimes Sublime shows a reindexing from the 95% of my project files (even if it reindexed already at the previous start), while other time there is just CPU consumption but no specific activity seems to be shown by Sublime.

I thought was a problem with the new ST build (yes, 3207 as well), but disabling GitGutter has instantly solved the lag & CPU problems.

I'm sorry, I have to confirm the issue.

EDIT: I cannot tell 100% that GitGutter is the culprit. CPU usage went back normal after disabling it, but then I got the same issue a couple of hours later.

--off-topic-- I found a temporary fix for the virtual machine hosting my project (the virtualbox process was taking 100% from the CPU), I write it to see if it helps anybody: if CPU is taken by VBoxHeadless, when using Sublime on a virtual machine passing via NFS, just go in the VM settings -> Audio and uncheck "Enable Audio Input". To me (don't ask me why) it takes the CPU usage to normal levels. Until I restart Sublime, at least.... 😖

Trying again other cases looks like GigGutter is not the direct responsible for the issue. So, at the moment is a mess, I can't tell whether GitGutter is provoking my problem. Ignore my confused poem. 😕

[RiseOoi]

Thank you, Pictor13, for your input.

Hmm, the authors are not replying, most probably our issue raising lacks of any way to reproduce the issue. Well, I don't really know how to reproduce the issue aside from installing it.

[Pictor13]

From the Command Palette you can choose to Disable or Enable a Package. So you can try quickly different combinations.

In my case I could improve generically things keeping GitGutter and disabling gpu_window_buffer; and the usual show_git_status, mini_diff.

On bigger project it still takes more than 10 seconds, after opening a file, to show any update of the gutters. It's pretty annoying since I can't quickly check the diff on a non-yet opened file. Files are shown as not modified for quite a while, even if they should show gutters.

There's no lag and the crazy file indexing as before, on ST in general. Even if at start of ST it ALWAYS keeps jumping to high CPU use, differently from the performant previous ST versions, but at least it doesn't do it for so long.

[deathaxe]

Did not see any kind of lags on Linux/Windows so far. Not sure which OS your on, insufficient info about that.

... gpu_window_buffer ...

... makes me guess you are on the buggy MacOS? According to the forum there are couple issues with buggy OpenGL APIs which make ST suffer from.

Furthermore ST needs to establish a lot more inotify objects to track changes being made to the .git folder, which may cause higher CPU utilization.

I have had the non_blocking set to true and livemode to false but no improvement.

1. The non_blocking option is not supported since ages as GG always runs in the background by default. Sure you run the latest build? No infos about that.
2. Disabling live_mode causes GG to keep idle during typing. So any input lag should not be caused by GG in this situation.

With GitGutter active, when working on a virtual machine mounted as NFS volume on my MacBook, the virtual machine is always using 50-100% of the CPU power for no apparent reason.

Git Diff

GitGutter creates a local copy of the committed file content. Any diff being made to create the gutter is created against this local copy. Therefore the location of your worktree/repo should not matter too much.

With ST 3207+ and "mini_diff": true the gutter markers are always created by ST's incremental diff. GitGutter just sets the reference document if you change the Compara Against ... target.

Git Status

There may probably be some delays when switching views due to git status calls which may take longer when run against a remote repo. But all of that runs in ST's asynchronous background thread and should therefore not cause lags with GUI updates or when typing.

Line Annoatation

Not sure how expensive the git blame calls are, if they run against a remote .git database directly, especially with large files. But this shouldn't be an issue with a local VM connected withe a virtual 1 or 10GBe network adapter.

You could disable git blame by ...

1. setting "git_gutter_show_line_annotation": false, in Preferences.sublime-settings and
2. removing the annotation stuff from the git_gutter_status_bar_text settings.

    "git_gutter_status_bar_text": [
        "{% if repo and branch %}",
            "{% if not st_git_status %}",
                "{{repo}}/{{branch}}",
                "{% if added_files + deleted_files + modified_files > 0 %}*{% endif %}, ",
            "{% endif %}",
            "{% if compare not in ('HEAD', branch, None) %}Comparing against {{compare}}, {% endif %}",
            "{% if state %}File is {{state}}{% endif %}",
            "{% if deleted > 0 %}, {{deleted}}-{% endif %}",
            "{% if inserted > 0 %}, {{inserted}}+{% endif %}",
            "{% if modified > 0 %}, {{modified}}≠{% endif %}",
            // "{% if line_author and line_author_age %}, ⟢ {{line_author}} ({{line_author_age}}){% endif %}",
        "{% endif %}"
    ],

[Pictor13]

Not really reopening, but more asking for an opinion.

---

In my case showing the gutters (regardless of enabling/disabling the show_line_annotation) takes from ~15 to ~30 seconds. I remember this to be a lot faster before I installed Sublime Text 3.2; am I wrong?

On ST I disabled already the show_git_status, mini_diff and gpu_window_buffer because of problems with mapping NFS volumes (files get locked preventing the umount, or when missing make ST crash abruptly).

---

Everything came back to be fast as usual when I disabled the show_status_bar_text, as suggested. Blazing fast again.

I wonder why this became slow with updating ST; and (I didn't look at the source code yet) I also wonder if the evaluation of the jinja2 template string could be parsed after having evaluated & set the gutters (the basic functionality), so to not slowdown productivity in case the show_status_bar_text is set to true. Having a delay is totally acceptable, when fetching more specific infos from blame, as it happens for the line annotations (that, to me, appear inconstantly after several seconds), while I believe the gutters should be provided as fast as possible when opening a file, regardless of the settings for other specific features.

@deathaxe, do you think this would be feasible?

[deathaxe]

I don't it is an jinja2 issue. The templates are quite simple and once compiled GitGutter keeps them cached.

I don't have much experience with working on network drives as I use git's ability to clone repos to my local harddisk, but I already noticed remarkable delays when working with Sublime Merge on a network share.

Calling git commands causes the index in the .git folder to be quieried more or less heavily, which I guess can take some time with larger repositories on a network share. Not sure what happens if Sublime Text reads from the same files to update its status info at the same time.

GitGutter.sublime-settings contains the following setting. Does setting "GIT_OPTIONAL_LOCKS": 1 change anything?

    "env": {
        "GIT_OPTIONAL_LOCKS": 0
    },

If disabling show_status_bar_text speeds things up, so much I guess git status -b -u -s to be the reason. Could you call this command against your repo and measure the time needed? This command is used to count all modified/untracked/ignored/added/deleted files and provide the {{modified}}, ... variables or jinja2 , in the repo each time a view is activated.

If anyone has an idea how to ask git to return the statistics directly, you're welcome.

[Pictor13]

Using the --no-optional-locks argument helps partially in speeding up (just in the cases where the index is not refreshed), but still takes ~5 seconds to process (run by shell). Keeping the GIT_OPTIONAL_LOCKS to 0 seems to speed up a little as well, but not always and not in a constant way; on some tests I couldn't notice any relevant difference in running times.

Looks like is the -b option to git status that slows down everything. In that case a refresh of the index is triggered and it takes that long time when over NFS.

I am not sure why the -b parameter causes this workload, differently from when calling the usual parameterless git status. But I wonder if the plugin could retrieve the branch name with a separate/different (and hopefully faster) git command.

[deathaxe]

I guess its because -b collects the stats about upstream and the commits the local one is ahead/behind.

All of those information are published as possible variables to be used in a statusbar message. To keep compatibility an alternative solution would require to provide those information as well.

I guess I could check if the statusbar template contains one of the vars retrieved by git status to decide whether to call git status or not.

[deathaxe]

Can you check, whether https://github.com/jisaacks/GitGutter/commit/4181ac2e9cf1bbebe0a153bcf6ee2b8187a6ba6a helps improving your situation?

To avoid calling git status you need to modify the status_bar_text setting to remove the related variables, which trigger git status.

    "status_bar_text": [
        "{% if repo and branch %}",
            "{% if not st_git_status %}",
                "{{repo}}/{{branch}}",
            "{% endif %}",
            "{% if compare not in ('HEAD', branch, None) %}Comparing against {{compare}}, {% endif %}",
            "{% if state %}File is {{state}}{% endif %}",
            "{% if deleted > 0 %}, {{deleted}}-{% endif %}",
            "{% if inserted > 0 %}, {{inserted}}+{% endif %}",
            "{% if modified > 0 %}, {{modified}}≠{% endif %}",
            "{% if line_author and line_author_age %}, ⟢ {{line_author}} ({{line_author_age}}){% endif %}",
        "{% endif %}"
    ]

[Pictor13]

Yyyeee! Thanks for the hyperfast help @deathaxe !

I didn't checkout the commit but just quickly copy/pasted the changes to a local copy, and it seems to work perfectly! 😃 Removing the default-template's 4th line "{% if added_files + deleted_files + modified_files > 0 %}*{% endif %}, ", the gutters appear super quickly! Max 4 seconds to execute; against the previous 10 to 30 seconds!

I find it a great addition! 🤗

[Pictor13]

Added a PR to fix a typo #548 . Sorry, I didn't notice it yesterday.