Description
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?