Git in EG very slow with large repositories or many programs open at once

[Proc_Fail]

Hi,

We are using SAS EG 7.1 in my organisation, and we are in the process of implementing Git version control.

We want to use Git partly because of the integration with EG, which allows basic committing and history checking from within EG. The aim is to minimise the additional burden on our analysts as far as possible when it comes to versioning.

The problem is that when the user clicks "Commit" within EG, while a program is open from a large(ish) repository, then SAS freezes for anything up to a minute or two before offering the commit dialogue.

These repositories are small by Git standards (a few hundred or thousand files and a few hundred Mb), but it is making Git unusable from within EG.

Any advice on things to try to speed up the process? Anyone having similar problems?

thanks

[CaseySmith]

Have you compared the performance of clicking the Commit button in EG to another Git GUI (ex. Git Extensions, SourceTree, etc.) to see if it is specific to EG or not?

Casey

[Proc_Fail]

Hi CaseySmith,

thanks for your reply. Yes, I'm comparing to any other Git GUI - the fallback is to use TortoiseGit (a few seconds to load the commit window, with any changed files). We have also used Sourcetree, GitKraken, VSCode... all take a reasonable length of time to Git commit.

In EG, it works quickly for a very small repository (tens of files), but it seems to be inefficient at processing changes in a larger repository, and maybe also when more than a couple of files are loaded in the EG project space.

Unfortunately I'm not sure how to log such an issue, as it is not SAS' internal processing - the session freezes and "grays out", not accepting input, until the process resolves. If you have any suggestions as to how our server admins could log it, I could speak to them.

[CaseySmith]

We'd like to take a look at your EG log to see if we can identify where the slowdown is occurring. You can turn on logging in EG via EG's Tools->Options->Application Logging. Check "Enable logging", note the log folder location (open Windows Explorer to it), then close EG. Then reproduce the problem in a new EG session and after the "freeze" (when the UI becomes responsive again), copy the generated log file to a different location (to limit the logging to only the problem scenario).

It's probably best to open a SAS Tech Support track for this issue, describing the problem, steps to reproduce, and attach the EG log. The track should come to us here in R&D. If you want to also attach the EG log to this thread, we can take an early look.

Casey

[Proc_Fail]

Hi Casey,

thanks for the replies, and sorry for the delay - I wanted to check with my server admins before posting logs. As I suspected, they are uneasy with posting logs to public forums, so I have opened a tech support ticket like you suggested (number 7612373200 for reference)

If I get a resolution I'll try to come back and post here to help others.

[CaseySmith]

Thanks @Proc_Fail. That (avoiding posting logs publicly) makes sense. I see the track and have access to the EG log you provided. We are investigating and will communicate back through Tech Support.

Casey

[Proc_Fail]

For others coming across this problem:

SAS tech support (probably including Casey above!) created a new .DLL file which helped improve matters - hopefully this will be included in a forthcoming hotfix.

Otherwise, here is the advice I received on how to minimise the problem:

the slowdown now seen will be directly related to the size of your EG project and the number of uncommitted files in GIT. SAS have to map each uncommitted SAS file to a program in the project, which means we are doing much more work than bringing up a single commit dialog like an external git client would.

R&D have commented that the easiest work around right now is for you to reduce the number of uncommitted files you have in GIT. 

This seems like a reasonable workaround - thanks to tech support for being very responsive!