Closing because this issue is a duplicate issue of SRCTREEWIN-2093.

Have you seen SRCTREEWIN-2093? It probably covers this issue.

I think "a half second flicker when switching between commits or files" pretty much sums it up. That might not be a bit deal for you, but I find that makes it unusable.

I've only tried Sourcetree sporadically, this time around I've decided to report the issues that I find most bothersome in hopes that the feedback (i.e. that a user has these issues) gives the developers some guidance to what needs addressing. Even if the developers just close my ticket because of lack of details, the feedback will have been given.

Re command line of course being faster – I've since tried a number of other git guis, and at least Git Extensions and git-cola "feel" close to on par with command line.

No, I do not work for Atlassian, but I am also sourcetree user. The reporter wrote a CR with practically no information about the specific development environment. As a fellow software engineer, I wouldn't have a clue how to investigate a problem description with such a lack of detail. Other users have been complaining about sourcetree performance for well over a year so the fact that he wrote that this is a recent phenomenon is quite strange. As I read CRs written by others, I like to vote for them if I have a similar issue. In this case, I can't vote for it since I don't understand the issue. I'm suggesting to the reporter that it would be a good idea to fully document the development environment within the CR description.

For instance the reporter indicated neither the OS (Windows 7, Windows 8, Windows 10), nor the GIT version. I see that another commenter is using TFS online/Git but the reporter did not write that. I'm also not sure what is meant by an "animated thingy". I do see a half second flicker when switching between commits or files, but it isn't that big of a deal. I've seen a lot of hostile comments being posted within source tree CRs lately, and I'm not quite sure how people think that is going to resolve anything.

Not sure what Shawn's comment is about or if he works for Atlassian, I still have a huge performance issue. Please help address the issue.

FYI, I am using TFS online/Git.

Thanks
Adel

I'm having a hard time understanding these comments. What is meant by it wasn't that bad until recently? Prior to the 1.7 version and above, there was a performance CR indicating major problems with slowness and responsiveness so that has been an issue for a long time now. Moreover, since I updated from v1.6 to v1.8 I have noticed significant improvements in responsiveness. I have seen it hang during a refresh occasionally, but besides that I do see improvements in responsiveness. This is the type of CR that seems quite subjective in meaning. I expect that GUI will always be slower than command line, to some degree. Without specific performance goals, I'm not sure how you could ever define "done" for a change request of this nature. A general statement that something is slow isn't going to help a developer understand the issue. For instance, is the actual GIT command taking longer or is this purely a CR about GUI responsiveness?

ST has been slower than command line, but it was not too bad until very recently.

At this point, I am frankly considering dropping it and only using command line which is not ideal.

Please help fix this

Thanks
Adel

I'd also like to see optimizations with regards to responsiveness and speed instead of icon tweaking.
As a long term WPF developer myself I know this is a really awful task, but a lot of people would appreciate it. In fact SourceTree is barely usable for medium to large projects with 50000+ LOCs, 20+ branches and 1000+ commits right now.

So here are some things you might consider:

• My own rule of thumb is to provide a visual feedback about the state of all actions that take longer than 300ms.
• Execute as much code as possible in an async fashion to improve responsiveness. Even if some operations really take that long, your UI can already deliver useful information or even take input from the user while loading in the background.
• {Binding IsAsync=True }

  seems to be buggy in WPF, throwing hard to debug exceptions from time to time, which can tear down your whole app (search for "internal WPF code tried to reactivate a BindingExpression"). So you might consider rolling your own solution, i.e. using lazy getters which return a surrogate value instantly and trigger a propertychanged when the callback completes.

• Trim down the visual tree as much as possible.
• Reduce the usages of complex grid layouts where possible. Using columns/rows with SharedSizeGroup="..." seems to be the worst for a decent performance.
• Use StaticResource instead of DynamicResource where possible.

Hope this helps.
Regards