This is still an issue when switching back and forward between databases even though they are (local). Please can you delay the refresh or just show the previous version and then refresh the update in the background to give a better perceived performance if nothing else? As it is clicking back and forward between databases can be quite a slow process

I just made a separate post for my proposal to use all cores for "registering database", so please vote if you observed the same behaviour and long for better performance:

https://redgate.uservoice.com/forums/39019-sql-source-control/suggestions/8853103-performance-use-all-available-cores-when-registe

When SOC says "registering database" only 1 CPU on the dev-machine is used. This step takes the longest amount of time, so optimizing SOC to use all CPUs (in my case 8!!) for that operation should speed up the whole thing

This would be great for us. Our database is not small. The operations for "Commit changes" and "Get latest" take somewhere between 20 and 30 seconds to complete. Otherwise great software. Thank you!

I would like the ability to 'Refresh Selected' or similar. Imagine I refresh the 'Commit Changes' window and get a bunch of differences. Following the principal of atomic commits, I really want to select different changes and group them into single commits... and then having committed those changes with one comment, I would like to go on and do the same for a different set of changes. It would be nice if I could just clear the selected items, or 'refresh' them, just to confirm that they had no further changes. That would leave the list a little clearer for the next commit.
You guys would probably like all our devs to use Source Control, but I am afraid it is not quite ready to be used by devs yet (performance being a key issue).

Trial version Data Compare 10 error: system.outofMemory.exception even though the RGTEMP system variable set to a large external disk folder. No success even after following these steps: http://documentation.red-gate.com/display/SDC10/Troubleshooting+System.OutOfMemoryException+during+comparison

We have exactly same issue. we are using sql 2008r2 and 2012.
We have one database with 500 tables and step 'Registering a database takes' more then 30 minutes !!! This is ridiculous. How I can use it on larger dbs.

I experienced the same problem

We love this product theoretically, but the performance is spectacularly bad in not one, but all of: speed (5-6 minutes per sync), memory consumption (GBs), TFS traffic (high), reliability (crashes SSMS all the time), data integrity (at least once a month we have to manually do a file-based check-in to rectify some confusion in the sync that then leaves the product unusable until the check-in is manually resolved).

I don't want to be negative, but this is such an outlier to normal red gate quality, and your premium prices mean you should have a stellar tool with maybe an occasional bug. This is two years running now. What could be more important?

Red gate - get on this. It's a major blemish to your otherwise excellent standards. Please.

3.1.4.72 Resolved the issue for me.

Just tried 3.1.3.26 and the initial syncing issues are still there. I outlined two observations the following forum post:
_http://www.red-gate.com/MessageBoard/viewtopic.php?p=60232#60232

I'm going back to 3.1.0.4829 again. =/

@Nicholas: Yeah, I also tried the latest and experienced the same issue. So I'm staying with 3.1.0.4829 for now.

So the issue does still seem to be in 3.1.2.33, but only when you first connect the database.

Still seem to have the issue in 3.1.2.33

Update: Downgrading to 3.1.0.4829 resolves the issue for me. It's a work around. I hope they make that installer available for others to download while they work on this.

Interesting, my Step 4 has greatly increased in time but I thought it was all related to this duplicate trigger error that Red Gate is working on. Apparently not. So I'm adding a vote for this one.
Coders are not very patient to sit there and listen to a disk spin and spit.

it appears that connection logic is broken and is ignoring the enabled transport settings. I consistently receive the "Named Pipes Provider" error during step 4. Why is red-gate trying to use Named Pipes when it is disable on both the client and server machines? Makes the tool completely unusable

So, true. It's now taking 5 minutes or more to complete step 4. Not sure how this is "A more reliable and less resource-intensive method for giving the username for changes in the shared model." per the release notes. I've been using RG tools for nearly 10 yrs now and have taken them into numerous shops. But over the last several releases of SQL Source Control it seems like the product is moving backwards.

I'm running on the "dedicated" configuration. Step 4 does take a very long time, however, it does complete for me. It has completed on two of my smallest databases. The larger databases are still running after ~20 minutes.

In order to improve performance, you need to change the base algorithm. If you stick with current logic and compare everything every time - this product will never work as expected and will even be unusable on db's with fair amount of objects. You should compare only what is changed since the last sync. modify_date in sys.objects is your friend!