SourceTree 2.0 for Windows – 3x faster than SourceTree 1.9
By Mike on May 5, 2017Performance was one of the key things we wanted to address while working on SourceTree 2.0 for Windows. It was a cause of frustration for many of you, and we knew we could do much better to improve your experience with SourceTree. Rather than focus on one performance attribute or one git command, we took a holistic approach. We looked at reducing the visual complexity of the UI, as well as the speed of many Git operations you love and use every day.
Visual Complexity
Visual complexity can be described as the number of elements displayed in an application; the more elements you have in your user interface, the more complex it is. SourceTree uses Windows Presentation Foundation (WPF) to render its user interface and the elements contained within. With WPF, interface elements are part of a composition tree, with each element in SourceTree’s interface adding one or more composition nodes to said tree. Whenever an element changes in the UI (e.g. an event occurs or an operation is performed in SourceTree) both a layout and redraw pass typically happens, as the tree is walked and rendering instructions executed for each composition node.
For visually complex applications (hello, SourceTree!) these passes look, from a user’s perspective, as stutters in the UI. So the general rule of thumb in light of this, along with the feedback we’ve received around performance, was to reduce the number of elements in SourceTree’s UI. We wanted to reduce the visual complexity of the application without losing the benefits of seeing the most important elements at the same time. We’ve actually been working at reducing this complexity for quite some time. So how do those elements stack up in SourceTree 2.0 for Windows compared to older versions?
Visual Complexity Across Versions – Corefx Repo
SourceTree Version 1.9/10: 1760 visual tree elements
How was it done?
- The file diff was rewritten to a custom text display control, which is now virtualized (only visible elements are part of the tree)
- The sidebar was rewritten to a custom virtualized tree view
- Bookmarks sidebar had a few icons removed
SourceTree Version 2: 1414 visual tree elements
How was it done?
- Bookmarks sidebar removed as it’s now in the “New Tab”
- The log view pills were rewritten to draw via custom function rather than have visual tree elements
Caching File Lists
Another improvement we made was the caching of views between the “File Status” and “Log / History” view. Before 2.0, switching between these views would cause the file lists to refresh each time, something that could take a few seconds depending on how many files you had. In 2.0, these views are no longer recreated when switching, eliminating the stuttering you used to see as the lists were refreshed.
SourceTree Version 1.9/1.10: No Caching
SourceTree Version 2.0: Caching
Git Performance
The performance of individual Git functions has a tremendous impact on the overall responsiveness of the application. SourceTree frequently runs background tasks, so any improvement typically has a cascading effect on higher-level features. For 2.0 we decided to add a hybrid LibGit2 handler for most Git operations in order to improve performance for most operations.
The results speak for themselves:
And of course you’ll also see improvements in other features you know and love like Git LFS support, bundles, SVN support, and interactive rebasing.
Try SourceTree 2.0 for Windows today
SourceTree 2.0 for Windows is a sign of things to come and we’re excited to see our hard work bear fruit in the hands of all of our users. We’re not done yet and will continue to work harder on further performance improvements, and if you have any feedback we’d love to hear from you.
Happy Coding!