Studio (and vs code) performace

[EnricoParisi]

Since I started testing git-source-control I noticed a severe performance impact in Studio.
Before reporting I wanted to make some analysis to provide some more detail other then "it slows Studio down".

Opening an item like a class or csp page is much slower when git-source-control is used, for example, opening studio with 10 classes take around 10 seconds.
Even closing Studio is slow when you have some class opened.

In my test case I have a total of 2285 items (classes and csp pages) defined in git-source-control and it is clear that more items you have defined, the slower Studio gets.

I've been trying to investigate the issue and I realized that the implementation is very, very, very....inefficient.

Just as en example here are a few measurement/call count that the implementation perform opening Studio with 10 classes:

32 calls to the ##class(SourceControl.Git.Utils).GitStatus() method. Note that this method call git.exe using $zf(-100), therefore is not "lighting fast".

40000+ calls to the ##class(SourceControl.Git.Utils).Type() method. I understand that this method "only" perform 78 global references and 1250 commands, bu calling it 40k+ times for opening 10 classes it seems a bit too much to me.

The worst problem is that after Studio has opened, it becomes very tedious to work with it, every action like moving the cursor, searching, typing is lagging, virtually impossible to comfortably work with it.

I think the issue is that Studio calls every few (5?) seconds the method ##class(SourceControl.Git.Extension).OnBeforeTimestamp(), this methods takes around 3.5 seconds to execute and perform 9'890'575 commands and 416'347 global references....every few seconds!

I haven't fully analyzed the vscode implementation, however from a preliminary test it seems a similar situation is present, apart from the lagging when editing that does not happen in vs code. In vscode it seems that the lagging happen when opening a class, changing active tab/class and performing server side operations like save/compile.

Bottom line, the current implementation is not suitable for any complex (I would say more that 500 items) environments.

Has anybody ever tested git-source-control with a significant (i.e. real world) number of items using Studio?

[isc-tleavitt]

@EnricoParisi I appreciate the analysis on this - see #269 which has some of the same. This is very much on our radar for the near term (this month).

[isc-tleavitt]

The fix boils down to a few key fixes, I think:

• Caching results in SourceControl.Git.Change:RefreshUncommitted and throttling calls to it (meaning, we call GitStatus less frequently)
• Caching the mapping between filename and InternalName and avoiding the listonly $System.OBJ.Load of files (most impactful thing for reducing time on a single call to RefreshUncommitted)
• Avoiding use of /SHELL when running git commands as much as possible to reduce $zf(-100) overhead (there are some newer features available in IRIS, in latest maintenance releases for 2021.1+, that help mitigate this need; see Permissions warnings on Linux #231 and associated PR for background)

Re: testing with a significant number of items using Studio, we've done this but not with the use case of initially opening a large number of files, which takes an annoying delay and amps it up to (annoying * number of files).

[isc-tleavitt]

This is covered by #318 which will be in the next release. @EnricoParisi if you want to try it out sooner you're welcome to!

[EnricoParisi]

Hi Tim, this is a grate news! In the coming week I'll be very busy but as I have time I surely would like to test it.
Sorry for my ignorance, how can I install it?