Low Description
Hello.
I recently added a new system drive to my ASUS ROG G751-JY, an M.2 NVMe SSD, in the hopes of gaining a lot of performance with Git and SourceTree, among other tools, by moving my projects from the stock HDD over to an SSD. The stock SSD was out of space, so I got this new one to replace it.
When I moved my repository to the new SSD, every SourceTree operation ran extremely slowly, as in it stalled for 20+ seconds just to commit a tiny change or update a view. I tried putting the stock SSD back in and doing the same things, thinking it was the switch from a non-NVMe SSD to an NVMe SSD, but it was the same bad performance.
The SSD(s) sit on an M.2 PCI-e interface; the stock one is non-NVMe and the new one is NVMe, so we're also testing the difference between those two. The mainboard's chips limit the bandwidth of the interface to PCI-e 2.0 4X speeds, which should still be magnitudes better than my HDD, but you can see the performance I get.
More info below the results, but you need to see these to care 
Time trials of SourceTree:
HDD 5400 RPM (ROG G751-JY stock) - SATA II slot - (Seq. read/write benchmarks: 101/93):
- Show initial "File Status" - 37.2 seconds
- Stage 1 file, few changes - 3.5 seconds
- Show History - 5.3 seconds
- Random update on File Status - 1.2 seconds
SSD NVMe (ROG G751-JY stock) - M.2 slot (Seq. read/write benchmarks: 1140/850):
- Show initial "File Status" - 44.5 seconds (+20%), sometimes 125 seconds (+336%)
- Stage 1 file, few changes - 22.3 seconds (+637%), sometimes 43 seconds (+1229%)
- Show History - 5.3 seconds (same), sometimes 40 seconds (+811%)
- Random update on File Status - 18 seconds (+1500%)
SSD NVMe (SN850) - M.2 slot (Seq. read/write benchmarks: 1615/1459):
- Show initial "File Status" - 41.5 seconds (+12%)
- Stage 1 file, few changes - 21.5 seconds (+614%)
- Show History - 5.2 seconds (-1%)
- Random update on File Status - 15 seconds (+1250%)
SSD NVMe{} (SN850) - External USB 3.0 NVMe interface (Seq. read/write benchmarks: 475/454):
- Show initial "File Status" - 45.1 seconds (+21%)
- Stage 1 file, few changes - 23.5 seconds (671+%)
- Show History - 45.3 seconds (+855%)
- Random update on File Status - 20 seconds (+1666%)
Result Elaboration and Discussion
I only included the sequential read/write marks; for the non-sequential tests, the SSDs are 40-400+ times faster than the HDD. I tried on the system partition and a secondary partition.
During these stalls, the CPU was at 10-40% usage (spread evenly across the cores) and the SSD at 0-2%. SourceTree would disappear from the Task Manager for most of the time of these stalls; it does that on HDD as well, but usually only for a short while before returning and updating the UI, but in these cases, SourceTree was gone from Task Manager for these long stalls until it finished. I'm on ethernet cable, so it's not Wi-Fi...nothing is stalled on any performance monitors.
And I did multiple tests for each of these results, made sure to turn off virus scanners, also adding exclusions for the folders for safety, everything else turned off and shut down. Ensured they were indexed by Windows, as well, like the original repo, and checked folder security settings. I always run SourceTree as Administrator. All that jazz.
I'm down to it being Git or SourceTree, that simply do not function well with my harddrives or their ports, or the drivers/interfaces for my ports/drives/mainboard not being optimized for what Git/SourceTree is doing. I've checked everything with these SSDs. They're formatted and adjusted properly, zipping and unzipping is fast and CPU-capped, games install and run using up to 425 MB/sec, and that's just what I've measured "in the field", but benchmarks are as expected for the ports, as well. It's just Git/SourceTree.
I know that everything on this machine is 6+ years old, but when everything else seems to be able to take advantage of the new disks, I'm running out of reasons to blame my system.