desktop: Updating the latest edition is very slow to use

Description

Version

  • GitHub Desktop:
  • Operating system:

Steps to Reproduce

Expected Behavior

Actual Behavior

Additional Information

Logs

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 18 (7 by maintainers)

Most upvoted comments

@shiftkey @tierninho

Environment

  • GitHub Desktop: v1.6.6
  • Operating System: Windows 10
  • Memory: 8GB, taken up around 54% - 58%
  • Application present: Chrome, VS Code, GitHub Desktop
  • My computer never had a reboot since a couple days ago. Hope that won’t affect.

Description

Slow performance in:

  • UI change. e.g. hovering among the ui elements, their background change with some delay. It appeared well after staying focused for a few seconds(> 8s), but switching from other applications made a disaster.
  • File diffs. Besides the focus thing above, the changed file diff shows after an unexpected delay(about 0.5s). I couldn’t find a way to rollback to 1.6.5 so that I’m not sure if this is normal. I suppose it’s longer than I expected.
  • Commit & undo. When commiting, the author form with summary and description changes incredibly slow, and it’s nothing to do with that focus thing. It’s slow always. So is the changed files list.

Logs

The Desktop was updated on 5-16, so I’ll paste these two log files.

And for comparison, here are the ones before update, in case you need them.

Repository

I’m currently working on my own project. You could fork and test if it may help.

I haven’t tested other repositories.

Note

I’m not a native English speaker. Hope things are well understood.

And if necessary, I could record a video for demonstration.

@zhaoty009 2019-05-20 13:26:11 Team from QQPCMgr has just fixed the issue. Everything should work as usual. A reboot is needed.

@luhaopeng thanks for working through this with us, and confirming this theory about anti-virus being a factor.

I’d love to confirm that this is isolated to this specific AV product, so please @zhaoty009 @health901 @havefive confirm that you are running the same product and the same workaround mentioned here https://github.com/desktop/desktop/issues/7540#issuecomment-493651528 addresses the issue for you, before we close this out.

Still, I’m curious why it is 1.6.6 that is awfully affected. I’ve tried 1.7.0-beta7 and it was affected much lesser. What’s the unique difference in 1.6.6 ?

I don’t have the full answer to this, but based on my experiences it can take anti-virus software some time to become aware of new updates and to trust them. When they encounter a new update they might act in one of two ways:

  • trusting - let the updated app proceed as is, based on code-signing values found and reputation of the entity that signed it
  • paranoid - not to trust the new update, and to inspect the app in case it’s trying to do something bad

While we mark one version as “beta” and the other as “production” the interesting difference here is when they were published:

  • 1.7.0-beta7 was released by us on the 9th of May, around 6pm UTC
  • 1.6.6 was released on the 15th of May, around 5pm UTC (almost a week later)
  • this issue was opened at approximately 2am UTC on the 16th of May (about 9 hours later the release was published)

My theory of what happened here is:

  • 1.7.0-beta7 had likely been installed and used enough for vendors to “see” it and know that it was safe
  • some people who updated to 1.6.6 as soon as it was available but also had an anti-virus program that didn’t trust the update
  • the anti-virus program would impede our Git processes from executing to the point it affected the overall experience of the app, because it needed to know that nothing bad was happening

“Process protection” does sound like something that would impact Desktop’s operations.

For reference, here are some old issues where anti-virus products impact GitHub Desktop - #2837 #5247 #5652. There’s not really much we can do here aside from work with the vendors to understand the problems better, so thank you again @luhaopeng for doing that on our behalf!

same issue